Вы просматриваете старую версию данной страницы. Смотрите текущую версию.

Сравнить с текущим просмотр истории страницы

« Предыдущий Версия 9 Текущий »

№

Название

стр

1

EGAIS состояние обработки ТТН

2

2

SASCHEDULE

6

3

SMPost

11

4

Алгоритм автоматической генерации заказа

20

5

Алгоритм наценивания. Беларусь

40

6

Алгоритм наценивания

48

7

Алгоритм расчета количества предложения заказа ЕТС (на базе процесса ORET)

54

8

Алгоритм расчета себестоимости в производстве

57

9

Алгоритм расчета среднесуточной реализации

60

10

Изменения функционала

66

11

Импорт данных из Microsoft Excel почтовым модулем

68

12

Сервер отчетов. Руководство администратора

75

13

Сравнение с эталоном

85

14

СупермагМобайл

86

15

Этикетки

108




Статусы документа ЕГАИС
Статус документа ЕГАИС, устанавливаемый Супермагом по мере обработки документа в поле SMEgaisDocHeader.DocState
Статусы ТТН на приход
EGAIS_DocStateInReceiving(0)Документ не готов (содержит только InformBReg, но не WayBill)
EGAIS_DocStateInReceived(1)Документ получен из ЕГАИС
EGAIS_DocStateInMatching(4)Накладная Супермага привязана к ТТН ЕГАИС, но ещё не до конца сопоставлена
EGAIS_DocStateInActSending(5)Акт приёма продукции отсылается в ЕГАИС
EGAIS_DocStateInFixed(6)ТТН зафиксирована в ЕГАИС
Статусы ТТН на отгрузку
EGAIS_DocStateOutDraft (10)Черновик ТТН на отгрузку
EGAIS_DocStateOutSending (11)ТТН на отгрузку подготовлена и отсылается в ЕГАИС
EGAIS_DocStateOutSended (12)ТТН на отгрузку отослана, ей присвоен WBRegID
EGAIS_DocStateOutActReceived(15)Получен Акт расхождения по данной ТТН
EGAIS_DocStateOutActConfirmed(16)Акт приёма продукции согласован
EGAIS_DocStateOutFixed (17)ТТН зафиксирована в ЕГАИС
Статусы акта постановки на баланс
EGAIS_DocStateACODraft(20)Черновик акта постановки на баланс
EGAIS_DocStateACOQueried(21)Акт постановки на баланс подготовлен и запрашивает данные по товарам из ЕГАИС
EGAIS_DocStateACOSending(22)Акт постановки на баланс отсылается в ЕГАИС
EGAIS_DocStateACOFormAB(23)Получены справки А и Б
EGAIS_DocStateACOFailed(24)Акт постановки на баланс содержит незарегистрированные товары
EGAIS_DocStateACORejected(25)Акт постановки на баланс отвергнут ЕГАИС
EGAIS_DocStateACOFixed(26)Получена квитанция о фиксации акта постановки на баланс в ЕГАИС
Состояние обмена с ЕГАИС – определяется квитанциями УТМ и ЕГАИС, заносится в поле SMEgaisDocHeader.ExchangeState
EGAIS_ExchStateErrorOrReject(-1)Обмен прекращён из-за ошибки или отказа
EGAIS_ExchStateOur (0)Требуется действие с нашей стороны
EGAIS_ExchStateQueried (1)Документ поставлен в очередь на отсылку
EGAIS_ExchStateSigned (2)Документ подписан УТМ
EGAIS_ExchStateEGAIS (3)Обработка на стороне ЕГАИС
EGAIS_ExchStateCounteragent(4)Обработка на стороне контрагента
EGAIS_ExchStateSuccess (5)Обмен успешно завершён
Тип акта приёма продукции (раньше определялся количеством недостачи), заносится в поле SMEgaisDocHeader.ActType
EGAIS_ActTypeAccept (A) Акт подтверждения
EGAIS_ActTypeDifference (D) Акт расхождения
EGAIS_ActTypeReject (R) Акт отказа

Старые статусы документа ЕГАИС в таблице SMEGAISDOCHEADER в поле DOCSTATE
До версии 1.033 сп1.
EGAIS_DocStateInDraft (0) Документ не готов (содержит только InformBReg, но не WayBill)
EGAIS_DocStateInReceived (1) Документ получен из ЕГАИС
EGAIS_DocStateInMatched (2) Документ ЕГАИС поставлен в соответствие с накладной Супермага
EGAIS_DocStateInFixed (3) Получена квитанция о фиксации ТТН в ЕГАИС
EGAIS_DocStateOutDraft (10) Черновик ТТН на отгрузку
EGAIS_DocStateOutStored (11) ТТН на отгрузку подготовлена и отсылается в ЕГАИС
EGAIS_DocStateOutSended (12) ТТН на отгрузку отослана, ей присвоен WBRegID
EGAIS_DocStateOutConfirmed (13) Получен Акт приёма продукции (акт расхождения) по данной ТТН
EGAIS_DocStateOutFixed (14) Получена квитанция о фиксации ТТН в ЕГАИС
EGAIS_DocStateACODraft (20) Черновик акта постановки на баланс
EGAIS_DocStateACOQueried (21) Акт постановки на баланс подготовлен и запрашивает данные по товарам из ЕГАИС
EGAIS_DocStateACOSended (22) Акт постановки на баланс отослан в ЕГАИС
EGAIS_DocStateACOFixed (23) Получена квитанция о фиксации акта постановки на баланс в ЕГАИС


Состояние – сочетание статуса документа ЕГАИС, типа документа, факта недостачи по всей ТТН, согласия / отказа с актом расхождения, результата фиксации цепочки документов в ЕГАИС
Для состояний с трехзначным номером первая цифра – номер базового состояния, например 200 – это 2 – сопоставлена с накладной + факт решения о нулевом приеме = Отказ отправлен в ЕГАИС.

Category(<span style="color: #a31515">"In"</span>) – ТТН на приход
<span style="color: #008000">0 - Документ не готов (содержит только InformBReg, но не WayBill) (Подстатус: InDraft)</span>
[ (<span style="color: #a31515">"Ожидается получение из ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InDraft = EGAIS_DocStateInDraft,
<span style="color: #008000">1 - Документ получен из ЕГАИС (Подстатусы: InReceived, InMatching)</span>
[ (<span style="color: #a31515">"Получена из ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InReceived = EGAIS_DocStateInReceived,
<span style="color: #008000">2 - Документ ЕГАИС поставлен в соответствие с накладной Супермага (Подстатусы: InRejected, InAccepted, InDifferenced)</span>
[ (<span style="color: #a31515">"Сопоставлена с накладной"</span>)]
InMatched = EGAIS_DocStateInMatched,
<span style="color: #008000">3 - Получена</span> <span style="color: #008000">квитанция</span> <span style="color: #008000">о</span> <span style="color: #008000">фиксации</span> <span style="color: #008000">ТТН</span> <span style="color: #008000">в</span> <span style="color: #008000">ЕГАИС (Подстатусы: InFixedRejected, InFixedAccepted, InFixedDifferenced, InFailedRejected, InFailedAccepted, InFailedDifferenced)</span>
[ (<span style="color: #a31515">"Зафиксирована</span> <span style="color: #a31515">в</span> <span style="color: #a31515">ЕГАИС"</span>)]
InFixed = EGAIS_DocStateInFixed,
<span style="color: #008000">200 - ТТН ЕГАИС полностью отклонена</span>
[ (<span style="color: #a31515">"Отказ отправлен в ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InRejected = 200,
<span style="color: #008000">201 - ТТН ЕГАИС полностью принята</span>
[ (<span style="color: #a31515">"Подтверждение отправлено в ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InAccepted = 201,
<span style="color: #008000">202 - ТТН ЕГАИС принята частично</span>
[ (<span style="color: #a31515">"Акт расхождения отправлен в ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InDifferenced= 202,
<span style="color: #008000">300 - Подтверждено полное отклонение ТТН ЕГАИС</span>
[ (<span style="color: #a31515">"Отказ принят ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InFixedRejected = 300,
<span style="color: #008000">301 - Подтверждено полное принятие ТТН ЕГАИС</span>
[(<span style="color: #a31515">"Подтверждение принято ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InFixedAccepted = 301,
<span style="color: #008000">302 - Подтверждено принятие ТТН ЕГАИС с расхождениями</span>
[ (<span style="color: #a31515">"Акт расхождения принят ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InFixedDifferenced = 302,
<span style="color: #008000">303 - Отказ полного отклонения ТТН ЕГАИС</span>
[ (<span style="color: #a31515">"Отказ отвергнут ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InFailedRejected = 303,
<span style="color: #008000">304 - Отказ полного принятия ТТН ЕГАИС</span>
[ (<span style="color: #a31515">"Подтверждение отвергнуто ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InFailedAccepted = 304,
<span style="color: #008000">305 - Отказ принятия ТТН ЕГАИС с расхождениями</span>
[ (<span style="color: #a31515">"Акт расхождения отвергнут ЕГАИС"</span>), Category(<span style="color: #a31515">"In"</span>)]
InFailedDifferenced = 305,

Category(<span style="color: #a31515">"Out"</span>) – ТТН на отгрузку
<span style="color: #008000">10 - Черновик ТТН на отгрузку (Подстатус: OutDraft)</span>
[ (<span style="color: #a31515">"Сопоставляется с накладной"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutDraft= EGAIS_DocStateOutDraft,
<span style="color: #008000">11 - ТТН на отгрузку подготовлена и отсылается в ЕГАИС (Подстатус: OutStored)</span>
[ (<span style="color: #a31515">"Отослана</span> <span style="color: #a31515">в</span> <span style="color: #a31515">ЕГАИС"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutStored= EGAIS_DocStateOutStored,
<span style="color: #008000">12 - ТТН на отгрузку отослана, ей присвоен WBRegID (Подстатус: OutSended)</span>
[ (<span style="color: #a31515">"Принята</span> <span style="color: #a31515">ЕГАИС"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutSended= EGAIS_DocStateOutSended,
<span style="color: #008000">13 - Получен</span> <span style="color: #008000">Акт</span> <span style="color: #008000">приёма</span> <span style="color: #008000">продукции (акт</span> <span style="color: #008000">расхождения) по</span> <span style="color: #008000">данной</span> <span style="color: #008000">ТТН (Подстатусы: OutConfirming, OutRejected, OutAccepted, OutDifferenced, OutAbortDifferenced)</span>
[ (<span style="color: #a31515">"Подтверждена"</span>)]
OutConfirmed= EGAIS_DocStateOutConfirmed,
<span style="color: #008000">14 - Получена</span> <span style="color: #008000">квитанция</span> <span style="color: #008000">о</span> <span style="color: #008000">фиксации</span> <span style="color: #008000">ТТН</span> <span style="color: #008000">в</span> <span style="color: #008000">ЕГАИС (Подстатусы: OutFixedRejected, OutFixedAccepted, OutFixedDifferenced, OutFailedRejected, OutFailedAccepted, OutFailedDifferenced)</span>
[ (<span style="color: #a31515">"Зафиксирован</span> <span style="color: #a31515">в</span> <span style="color: #a31515">ЕГАИС"</span>)]
OutFixed= EGAIS_DocStateOutFixed,
<span style="color: #008000">100 - Накладная Супермага привязана к ТТН ЕГАИС, но ещё не до конца сопоставлена</span>
[ (<span style="color: #a31515">"Сопоставляется с накладной"</span>), Category(<span style="color: #a31515">"In"</span>)]
InMatching = 100,
<span style="color: #008000">101 - Требуется подтвердить или отклонить Акт приёма продукции</span>
[ (<span style="color: #a31515">"Акт расхождения получен из ЕГАИС"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutConfirming = 101,
<span style="color: #008000">203 - ТТН ЕГАИС полностью отклонена</span>
[ (<span style="color: #a31515">"Акт отказа получен из ЕГАИС"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutRejected= 203,
<span style="color: #008000">204 - ТТН ЕГАИС полностью принята</span> <span style="color: #808080">></span>
[ (<span style="color: #a31515">"Акт подтверждения получен из ЕГАИС"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutAccepted= 204,
<span style="color: #008000">205 - ТТН ЕГАИС принята частично</span>
[ (<span style="color: #a31515">"Акт расхождения согласован"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutDifferenced = 205,
<span style="color: #008000">206 - Отказ от частичного принятия ТТН</span>
[ (<span style="color: #a31515">"Акт расхождения отклонен"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutAbortDifferenced = 206,
<span style="color: #008000">306 - Подтверждено полное отклонение ТТН ЕГАИС</span>
[ (<span style="color: #a31515">"Акт отказа согласован"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutFixedRejected = 306,
<span style="color: #008000">307 - Подтверждено полное принятие ТТН ЕГАИС</span>
[ (<span style="color: #a31515">"Акт подтверждения согласован"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutFixedAccepted = 307,
<span style="color: #008000">308 - Подтверждено принятие ТТН ЕГАИС с расхождениями</span>
[ (<span style="color: #a31515">"Согласие с актом расхождения принято ЕГАИС"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutFixedDifferenced = 308,
<span style="color: #008000">309 - Подтверждено отклонение ТТН ЕГАИС с расхождениями</span>
[ (<span style="color: #a31515">"Отклонение акта расхождения принято ЕГАИС"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutFixedAbortDifferenced = 309,
<span style="color: #008000">310 - Отказ полного отклонения ТТН ЕГАИС</span>
[ (<span style="color: #a31515">"Акт отказа отклонен"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutFailedRejected = 310,
<span style="color: #008000">311 - Отказ полного принятия ТТН ЕГАИС</span>
[ (<span style="color: #a31515">"Акт подтверждения отклонен"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutFailedAccepted = 311,
<span style="color: #008000">312 - Отказ принятия ТТН ЕГАИС с расхождениями</span>
[ (<span style="color: #a31515">"Согласие с актом расхождения отвергнуто ЕГАИС"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutFailedDifferenced = 312,
<span style="color: #008000">313 - Отказ отклонения ТТН ЕГАИС с расхождениями</span>
[ (<span style="color: #a31515">"Отклонение акта расхождения отвергнуто ЕГАИС"</span>), Category(<span style="color: #a31515">"Out"</span>)]
OutFailedAbortDifferenced = 313
Акт постановки на баланс
<span style="color: #008000">20 - Черновик акта постановки на баланс</span>
[ (<span style="color: #a31515">"Черновик"</span>), Category(<span style="color: #a31515">"ActChargeOn"</span>)]
ActChargeOnDraft= EGAIS_DocStateACODraft,
<span style="color: #008000">21 - Акт постановки на баланс подготовлен и запрашивает данные по товарам из ЕГАИС</span>
[ (<span style="color: #a31515">"Запрашивает данные по товарам"</span>), Category(<span style="color: #a31515">"ActChargeOn"</span>)]
ActChargeOnQueried= EGAIS_DocStateACOQueried,
<span style="color: #008000">22 - Акт постановки на баланс отослан в ЕГАИС</span>
[ (<span style="color: #a31515">"Отослан</span> <span style="color: #a31515">в</span> <span style="color: #a31515">ЕГАИС"</span>), Category(<span style="color: #a31515">"ActChargeOn"</span>)]
ActChargeOnSended= EGAIS_DocStateACOSended,
<span style="color: #008000">23 - Получена квитанция о фиксации акта постановки на баланс в ЕГАИС</span>
[ (<span style="color: #a31515">"Зафиксирован</span> <span style="color: #a31515">в</span> <span style="color: #a31515">ЕГАИС"</span>), Category(<span style="color: #a31515">"ActChargeOn"</span>)]
ActChargeOnFixed= EGAIS_DocStateACOFixed,





Описание системы выполнения заданий по расписанию
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Общие принципы</span></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Функции управления выполнением заданий</span></span> ]
[<span style="color: #0000ff"><em><span style="text-decoration: underline; ">Создание нового задания</span></em></span> ]
[<span style="color: #0000ff"><em><span style="text-decoration: underline; ">Редактирование расписаний</span></em></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Функции администрирования базы данных</span></span> ]
[<span style="color: #0000ff"><em><span style="text-decoration: underline; ">Перестроение индексов</span></em></span> ]
[<span style="color: #0000ff"><em><span style="text-decoration: underline; ">Анализ таблиц и индексов (сбор статистики)</span></em></span> ]
[<span style="color: #0000ff"><em><span style="text-decoration: underline; ">Сбор статистической информации и перестроение индексов.</span></em></span> ]
[<span style="color: #0000ff"><em><span style="text-decoration: underline; ">Перекомпиляция объектов</span></em></span> ]
[<span style="color: #0000ff"><span style="text-decoration: underline; ">Сбор 'мусора'</span></span> ]

Общие принципы

В основу системы выполнения заданий по расписанию положен, имеющийся в ORACLE, механизм заданий (JOB). Пользователю в едином интерфейсе предоставляется информация обо всех заданиях, которые уже созданы (любыми способами) или могут быть созданы с помощью описываемой системы в схеме пользователя SUPERMAG.
Информация о заданиях, которые могут быть созданы храниться в таблице SASchedule. Представление SVJobs показывает обобщенную информацию обо всех заданиях. Таблицы SASchedDateList и SASchedDates предназначены для хранения произвольных именованных списков дат, в которые должны выполняться задания. Процедуры и функции системы выполнения заданий по расписанию находятся в пакете Schedule.
Структура таблицы SASchedule

Колонка

Тип данных

Описание

ID

NUMBER(10)

Id задания (из последовательности SAScheduleSEQ)

NAME

VARCHAR2(100)

Наименование операции (задания)

WHAT

VARCHAR2(4000)

PL/SQL текст выполняемой операции

INTERVAL

VARCHAR2(200)

PL/SQL текст функции, задающей периодичность выполнения задания


Функции управления выполнением заданий



рис. 1
Внешний вид экранной формы, предназначенной для управления заданиями, показан на рисунке №1. Доступ к этой форме имеет только пользователь SUPERMAG.
Информация о заданиях представлена в виде таблицы со следующими колонками:

  • Job – номер задания ORACLE, выполняющего данную операцию
  • OK – признак работоспособности задания
  • Название – наименование операции
  • Интервал – описание правила определения даты выполнения
  • Следующий – дата следующего выполнения операции
  • Последний – дата последнего выполнения операции


Имеется возможность сортировки записей по значению в любой изколонок.
Если поле Job пустое, то это значит, что задание для выполнения операции, указанной в поле Название, не создавалось. Создать задание можно, нажав кнопку Вкл/Выкл.
Если поле Job содержит номер задания, но нет отметки в поле OK, то это значит, что задание существует, но переведено в нерабочее состояние (BROKEN). Об этом, так же, свидетельствует значение '01.01.4000' в поле, указывающем дату следующего выполнения операции. Включить и выключить задание можно, нажав соответствующую кнопку Вкл/Выкл.
Поле Название содержит наименование операции в том случае, если системе удалось отождествить выполняемое задание с одной из строк в таблице SASchedule. Отождествление ведется по PL/SQL тексту выполняемой операции. В противном случае это поле содержит PL/SQL текст выполняемой операции.
Поле Интервал содержит описание периодичности выполнения задания. Если PL/SQL текст функции, задающей периодичность выполнения задания, не удалось отождествить ни с одним из способов задания периодичности предусмотренным в системе, то вместо описания в это поле помещается непосредственно PL/SQL текст функции, задающей периодичность.
Следует обратить внимание на возможность однократного выполнения операции. Если в поле Интервал указано Однократно, то после создания задания оно будет немедленно выполнено и удалено. Запись в SASchedule при этом останется, и есть возможность повторить операцию. В таком режиме удобно выполнять процедуры, требующие много времени для их выполнения, т.к. нет необходимости ждать завершения работы процедуры.
Кнопка Создать предназначена для вызова диалога создания нового задания. Внешний вид формы диалога показан на рисунках 2 и 3.
Кнопка Удалить служит как для удаления задания, так и для удаления информации из таблицы SASchedule. Если она нажата в строке, где определено задание ORACLE (заполнено поле Job), то удаляется только задание ORACLE. Если же задание ORACLE не определено, то пользователю выдается предупреждение и после его подтверждения удаляется запись из таблицы SASchedule.
Кнопка Обновить служит для обновления информации в экранной форме.
Кнопка Расписания предназначена для вызова диалога редактирования расписаний. Внешний вид формы диалога показан на рисунке 4. Этот диалог предназначен только для работы с существующими расписаниями. Новое расписание можно создать при создании задания, работающего по этому расписанию.

Создание нового задания



рис. 2

рис. 3
Диалог создания нового задания (рисунки 2 и 3) изменяется в зависимости от выбранной периодичности выполнения задания. Каждому типу периодичности соответствует свой набор параметров.
При выбранном режиме выполнении задания По расписанию можно выбирать расписания из списка, вводить новые расписания и удалять не нужные. Кроме того, доступен переход в диалог редактирования расписания (кнопка с изображением часов).
Поля Дата старта заполняются текущей датой при инициализации диалога, и служат для указания времени первого выполнения задания. Время следующего выполнения вычисляется на основании заданной периодичности. Если указанные дата и время старта задания в момент нажатия кнопки OK будут меньше текущего времени на сервере, то задание будет выполнено немедленно, как если бы в этих полях стояла текущая дата и время. При создании заданий секунды в указанном времени старта не учитываются.

Редактирование расписаний



рис. 4
Этот диалог предназначен только для работы с существующими расписаниями. Даты старта заданий показываются отсортированными в порядке убывания. Имеется возможность удалить расписание, ели оно не используется реальными заданиями, добавить или удалить дату старта в расписание и удалить 'хвост' расписания до текущей даты. Диалог ввода новой даты показан на рисунке 5.

рис. 5
При включении в расписание новой даты старта секунды в указанном времени старта не учитываются.

Функции администрирования базы данных


Для поддержки выполнения действий по администрированию базы данных создан пакет Trace. Процедуры этого пакета, будучи соответствующим образом включенные в тексты прикладных процедур, позволяют проводить протоколирование работы этих прикладных процедур, и регистрировать возникающие ошибки. При этом, предупреждения и сообщения об ошибках регистрируются всегда, а трассировочная и отладочная информация, только если включен такой режим. Включение и выключение режима трассировки производиться процедурами Trace_ON и Trace_OFF соответственно. Установленный режим сохраняется в системном параметре с именем 'Trace'. Все сообщения сохраняются в таблице SSEventLog.
Процедуры, предназначенные непосредственно для выполнения административных функций, находятся в пакете DBAdmin. Они позволяют проводить перестроение индексов, анализ таблиц и индексов (сбор статистики) и перекомпиляцию инвалидных объектов. Многие процедуры имеют такой параметр, который ограничивает время работы процедуры. Необходимо иметь в виду, что ORACLE не является системой реального времени, и нет возможности прекратить выполнение процедуры в произвольный момент времени. Механизм ограничения времени работы процедур основан на том, что в них некие действия выполняются в цикле, поочередно над большим количеством объектов, и на каждой итерации перед обработкой очередного объекта проводится контроль отработанного времени. Значение лимита времени указывается в минутах. Если этот параметр не задан, то считается, что ограничений по времени нет.

Перестроение индексов

Для перестроения индексов используется процедура Indexes_Rebuild. Первый ее параметр задает минимальную глубину бинарного дерева индекса, при которой он перестаивается. Если указать 0 или NULL, то вместо перестроения индекса производиться объединение блоков 'листьев' (COALESCE) и статистика при этом не собирается. Второй параметр определяет необходимость сбора статистики при перестроении. Третий параметр задает лимит времени работы в минутах. Последний, четвертый, параметр задает табличное пространство для нового размещения индексов, если необходим их перенос в другое табличное пространство.

Анализ таблиц и индексов (сбор статистики)

Процедура Tables_Analyze производит сбор статистики по таблицам и индексам. Единственный ее параметр задает ограничение времени работы в минутах.

Сбор статистической информации и перестроение индексов.

Процедура Analyze_and_Rebuild производить сбор статистики по таблицам и индексам, и перестраивает индексы глубина бинарного дерева, которых больше двух. Единственный ее параметр задает ограничение времени работы в минутах.

Перекомпиляция объектов

Процедура ReCompileAll предназначена для поиска инвалидных объектов и их автоматической перекомпиляции. Она может периодически выполняться в профилактических целях.

Сбор 'мусора'

Для периодического выполнения профилактических технологических операций создана специальная процедура GarbageCollector. Периодичность работы GarbageCollector не регламентируется, поэтому в процедуру должны включаться только такие операции, не выполнение которых не влияет критически на работоспособность системы в целом.
В настоящее время GarbageCollector содержит только одну операцию: удаление промежуточной информации, используемой при генерации номеров документов.

Введение

В данном документе описан протокол и основные принципы работы почтового модуля торговой системы Супермаг 2000, далее именуемого SMPost.

Назначение

Почтовый модуль (ПМ) предназначен для осуществления обмена данными между базами данных (БД) узлов торговой системы (ТС). В составе ТС могут быть как узлы, использующие БД в формате Супремаг 2000, так и узлы, использующие иные типы БД, например, узлы Супермаг 2.х с БД Paradox. Почтовый модуль ТС работает только с БД Супермаг 2000, но предоставляет интерфейс обмена данными с узлами других типов. В случае однородной среды, т.е. только узлы Супермаг 2000, никаких дополнительных компонентов для осуществления обмена данными между узлами помимо тех, что входят в состав ПМ, не требуется. В разнородных средах дополнительно потребуются компоненты, написанные в соответствии со стандартами ПМ и обеспечивающие интерфейс к узлам с БД других типов.

Общая схема

На рис. представлена общая схема взаимодействия компонентов почтового модуля.


SMPostТранспорт пакетовБД узла 1БД узла 2Обработчики типов объектовФильтр типа БДКомпоненты ПМ узла 2Компоненты
ПМ узла 1
Виртуальный пакетФизический пакет





















На схеме представлены два взаимодействующих узла торговой системы. ПМ узла 1 (программа SMPost) осуществляет общее управление работой других компонентов ПМ данного узла, которые разделяются на две группы: обработчики типов объектов и фильтры типов БД.
Для каждого типа объектов Супермага (таких как «документы», «карточки складского учета» и т.д.) имеется свой обработчик. Задачей обработчика типа объектов является сохранение объектов данного типа в файле виртуального пакета (ВП), а также загрузка этих объектов в БД из ВП, поступившего от другого узла.
После того как ВП сформирован, он предобразуется в физический пакет (ФП). Это преобразование осуществляется с помощью фильтра типа БД. На данном узле ТС должны быть установлены фильтры для всех типов БД, с которыми непосредственно взаимодействует этот узел. Фильтр БД Супермаг 2000 входит в состав стандартных компонентов ПМ.
Сформированный с помощью фильтра файл ФП пересылается на узел 2 посредством транспорта пакетов (ТП).
После доставки ФП на узел 2 он загружается компонентами ПМ этого узла в БД. ПМ узла 2 может быть как ПМ Супермаг 2000, и тогда его структура аналогична структуре ПМ узла 1, так и ПМ другой системы, имеющий в своем составе средства работы с ФП, сформированным фильтром для БД соответствующего типа. Обработав полученный ФП, узел 2 отправляет на узел 1 пакет-подтверждение по содержимому которого ПМ отправителя определяет, были ли посланные данные успешно приняты. Формат пакета-подтверждения является стандартным независимо от типа БД.
При пересылке информации с узла 2 на узел ПМ узла 2 формирует ФП, который доставляется ТП на узел 1. Здесь поступивший ФП посредством фильтра преобразуется в ВП. Затем содержимое ВП загружается в БД узла 1 с помощью вызовов обработчиков типов объектов.

Пакеты

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

Виртуальный пакет

Виртуальный пакет (ВП) имеет стандартный формат и представляет собой структурированное хранилище OLE. При отправке данных из узла Супермаг 2000 ВП формируется ПМ с помощью вызова соответствующих обработчиков типов объектов. При приеме данных узлом Супермаг 2000 ВП формируется фильтром типа БД, от которой поступил физический пакет.

Физический пакет

Физический пакет — это файл, содержащий информацию ВП, и предназначенный для пересылки посредством ТП на узел соответствующего типа. Формат ФП определяется фильтром типа БД, который при отправке данных из узла Супермаг 2000 преобразует ВП в ФП.

Пакет-подтверждение

Пакет-подтверждение формируется принимающей БД по результатам обработки поступившего ФП. Формат пакета-подтверждения стандартный и не зависит от типа БД. В случае узла Супермаг 2000 пакет-подтверждение формируется и передается ТП непосредственно ПМ без участия обработчиков или фильтров. В случае БД иных типов в составе их ПМ должны быть средства, позволяющие формировать и отправлять пакеты-подтверждения.

Дерево узлов ТС

Взаимодействующие посредством ПМ узлы ТС логически объединяются в дерево (ациклический направленный граф). Непосредственная пересылка данных возможна только между непосредственно связанными родительским и дочерним узлами дерева. Управляющей БД для БД данного узла является БД родительского узла. У каждого узла имеется не более одной родительской БД (может не быть вообще). Каждая БД в свою очередь может быть управляющей для нескольких БД дочерних узлов дерева. Количество дочерних узлов произвольно.
ПМ Супермага 2000 поддерживает следующие режимы рассылки ВП:

  • отправка ВП в управляющую БД
  • отправка ВП в одну из дочерних БД
  • отправка ВП всем дочерним БД.

Таким образом, один ВП может быть разослан нескольким БД. В этом случае ВП формируется однократно, после чего с помощью соответствующих фильтров формируется необходимое число ФП — по одной для каждой БД адресата.
Структура непосредственно окружения данного узла задается в рабочих таблицах SMPost в БД этого узла. Для каждого смежного узла указывается тип используемой там БД и параметры пересылки ФП, такие как периодичность повторных посылок ФП в случае неполучения пакета-подтверждения из БД адресата.
Для каждого узла в рабочих таблицах SMPost указываются два каталога: каталог исходящих сообщений и каталог входящих сообщений. В первый помещаются ФП, предназначенные для отправки в соответствующий узел. ТП должен иметь средства выборки ФП из каталогов исходящих сообщений. В каталог входящих ФП ТП должен помещать пакеты, прибывшие из соответствующего узла. Это могут быть как ФП, так и пакеты-подтверждения.

Общий алгоритм отправки объектов

Для того, чтобы объект был обработан ПМ Супермаг 2000, он должен быть поставлен в очередь ПМ, что осуществляется посредством помещения соответствующей записи в таблицу SMPostQueue.
Программа ПМ SMPost.exe с заданной периодичностью просматривает эту таблицу и группирует находящиеся в ней объекты в ВП. В один ВП объединяются все объекты, предназначенные для отправки в БД определенного узла. Объекты, которые должны быть разосланы по всем дочерним БД, также объединяются в один пакет. Новый ВП может быть также сформирован в любой момент с помощью вызова соответствующей сохраненной процедуры. Одновременно с формированием ВП формируется один или несколько соответствующих ему ФП. При этом записи о новых ФП помещаются в таблицу SMPostPackages. Если отправка данных в соответствующую БД заблокирована в момент формирования ФП, то ФП для этой БД сформирован не будет. В том случае, когда из-за блокировки отправки не было сформировано ни одного ФП, ВП уничтожается и входящие в него объекты изымаются из очереди ПМ.
Информация о сформированных ВП хранится в таблице SMPostVirtPacks. Периодически программа SMPost просматривает эту таблицу и при обнаружении в ней новых записей приступает к генерации файлов новых ВП. Файлы ВП размещаются в каталоге виртуальных пакетов, расположение которого в файловой системе хранится в таблице параметров ПМ SMPostParam. Этот каталог должен быть доступен программе SMPost по чтению и записи. При указании каталога ВП рекомендуется использовать имена UNC в формате \\server\share\path. Использование путей, начинающихся с буквы диска, не рекомендуется, но допускается.
При генерации файла ВП SMPost вызвает обработчики типов объектов для записи в ВП объектов, подлежащих отправке. Если один и тот же объект попал в данный ВП многократно (т.е. был поставлен в очередь на отправку несколько раз), то в ВП попадает последняя версия данных объекта.
После того, как ВП успешно сформирован, SMPost приступает к генерации файла ФП. В общем случае для преобразования ВП в ФП вызывается фильтр типа БД назначения. Полученный в результате работы фильтра ФП помещается в каталог исходящих сообщений БД назначения.
ТП должен периодически просматривать каталоги исходящих сообщений и выполнять пересылку появляющихся там файлов ФП. После того как ФП успешно отправлен адресату (но до получения подтверждения об успешной обработке ФП адресатом) файл ФП должен быть удален транспортом из каталога исходящих сообщений.
С заданной периодичностью SMPost просматривает имеющийся в БД узла список сгенерированных ФП. Если файл соответствующего ФП не обнаружен в каталоге исходящих сообщений, но пакет-подтвержение из узла-адресата не получен, то SMPost предполагает сбой пересылки пакета на уровне ТП. В этом случае SMPost снова формирует ФП для повторной попытки пересылки.
Когда ТП помещает в каталог входящих сообщений пакет-подтверждение, SMPost по содержимому этого пакета определяет ВП, и помечает ФП, сгенерированный на основе данного ВП для отправки данному адресату, как успешно обработанный (в том случае, если пакете-подтверждении содержится информация об успешном приеме пакета). Когда для всех ФП, соответствующих данному ВП, будут получены пакеты-подтверждения успешного приема, SMPost считает ВП успешно отправленным и выполняет очистку ВП. Очистка ВП включает в себя удаление файлов ВП и ФП (если последние не были удалены ТП), удаление записей о ВП и ФП из таблиц SMPostVirtPacks и SMPostPackages, а также удаление объектов, входящих в ВП, из очереди ПМ (SMPostQueue).

Общий алгоритм приема объектов

SMPost с заданной периодичностью просматривает содержимое каталогов входящих сообщений всех узлов, зарегистрированных в его рабочих таблицах. При обнаружении нового файла ФП SMPost преобразует его в ВП посредством вызова фильтра типа БД отправителя. ВП формируется в том же каталоге, в котором расположен ФП (т.е. в каталоге входящих сообщений БД-отправителя). Далее с помощью обработчиков типов объектов содержимое ВП загружается в БД узла. По результатам загрузки формируется пакет-подтверждение, который помещается в каталог исходящих сообщений БД-отправителя и далее с помощью ТП перемещается на узел-отправитель.
Начиная с версии 1.018 поддерживается параллельный прием пакетов от разных БД (пакеты, приходящие от одной и той же БД, обрабатываются последовательно). Максимальное количество потоков для приема задается в оснастке (snap-in) консоли управления на закладке "Параметры" под названием "Число потоков для приема". Значение должно находитъся в пределах от 1 до 32 включительно. Попытка установить значение вне указанного диапазона отвергается программой. Если же значение вне диапазона как-то попало в базу, то почтовый сервер не стартует (для этой базы).
Фактическое количество потоков для приема для данной принимающей БД не превышает количества сконфигурированных для нее (на закладке "Конфигурация") внешних баз данных. Каждый активный поток приема требует установки отдельной сессии с базой данных.

Специальные режимы обмена

Отключение фильтрации

Для удаленной базы данных может быть выбран режим обмена без фильтрации. В этом режиме фильтр типа базы данных не используется. ФП создается в соответствующем каталоге исходящих сообщений путем простого копирования ВП (с переименованием). Принимающая сторона должна быть способна обработать ФП, который фактически является ВП, т.е. также без применения фильтра. После обработки полученного ВП пакет-подтверждение возвращается обычным способом.
Если для удаленной базы данных указан формат, отличный от «sm2000», то режим отключения фильтрации игнорируется и фильтр будет вызван.

Сохранение .bak файлов

В данном режиме входящие физически пакеты по окончании обработки не удаляются, но переименовываются с расширением .bak. Режим предназначен для отладочных целей и использовать его при нормальной работе не рекомендуется: bak-файлы должны удаляться вручную. В режиме отключенной фильтрации данный флаг игнорируется.

Транспорты

Транспорт пакетов — это программный модуль, осуществляющий транспортировку информации между локальной и удаленной базами. Этой информацией могут быть физические пакеты и пакеты-подтверждения. При отправке пакета транспорт должен извлечь его каталога исходящей информации, выделенного для обмена с данной удаленной базой, и отправить по адресу этой базы, формат которого, а равно и способ отправки, определяется конкретным транспортом. Кроме того, транспорт должен обеспечивать прием пакетов от удаленной базы с их помещением в соответствующий каталог входящей информации. После того, как пакет отправлен, транспорт должен удалить его из каталога исходящих сообщений.
ПМ поддерживает встроенные и внешние транспорты. Встроенные транспорты реализованы самим ПМ. Внешние транспорты представляют собой независимые программы. Способы настройки, запуска и управления внешними программами не определяются ПМ. Однако, внешняя программа транспорта должна при чтении\записи файлов из каталогов входящей\исходящей информации должна учитывать и правильно обрабатывать возможные конфликты при обращении к одним и тем же файлам одновременно с ПМ. В частности, внешний транспорт должен перед началом работы с файлом пакета (как при чтении, так и при записи) заблокировать его в монопольном режиме. Это позволит избежать попыток отправки файлов, которые не до конца сформированы ПМ, а также попыток приема ПМ файлов, обработка которых транспортом еще не завершена.

Встроенные транспорты

В настоящий момент поддерживаются следующие встроенные транспорты:

  • прямой обмен;
  • файловый
  • FTP
  • E-mail.

При использовании встроенных транспортов ПМ на обеих стронах должен быть настроен на один и тот же тип транспорта.
Для каждого встроенного транспорта определен набор параметров, требующих надлежащей настройки, прежде чем транспорт можно будет использовать. Параметры встроенных транспортов разделяются на универсальные, которые влияют на работу транспорта в целом и настраиваются для локальной базы, и частные, которые задаются для каждой удаленной базы данных.
Универсальными параметрами всех встроенных транспортов, за исключением транспорта прямого обмена, являются параметр interval («Частота опроса») и параметры дозвона, обсуждаемые в разделе «Дозвон».
Универсальный параметр interval («Частота опроса») задает промежутки времени между двумя последовательными активизациями данного транспорта. За одну активизацию транспорт выполняет опрос всех каталогов исходящих сообщений и отправку имеющихся в них пакетов, а также помещает в каталогих входящих сообщений все пакеты, прибывшие от удаленных баз.

Конверты

Все встроенные транспорты, за исключением транспорта прямого обмена, используют для обмена информацией с ПМ, так называемые, конверты. Конверт представляет собой файл специального формата, содержащий внутри себя один физический пакет, или один пакет-подтверждение.
Для исходящего пакета конверт формируется ПМ. Транспорт может группировать несколько пакетов в одну посылку, однако, на принимающей стороне такая посылка должна быть снова разобрана транспортом на конверты, которые и помещаются затем в каталог входящих сообщений. Имя файла конверта имеет расширение «ENV». Транспорт пересылает конверты строго в порядке дат последнего изменения файла для обеспечения правильной последовательности обработки пакетов на принимающей стороне.

Прямой обмен

Транспорт «прямой обмен» является фактически нуль-транспортом. В этом режиме два ПМ Супермага 2000 напрямую работают с общими каталогами обмена данными.
Два узла, взаимодействующие в режиме прямого обмена, должны быть сконфигурированы так, что каталог исходящих сообщений узла 2 на узле 1 соответствует каталогу входящих сообщений узла 1 на узле 2. Аналогично должен быть сконфигурирован каталог исходящих сообщений. В режиме прямого обмена принимающий узел не удаляет ФП после его обработки, но усекает файл пакета до нулевого размера. Это позволяет избежать повторных попыток пересылки ФП отправляющим узлом. Пакет-подтверждение помещается принимающим узлом в каталог исходящих сообщений отправляющего узла, который для последнего является каталогом входящих сообщений первого. Получив сообщений об успешном приеме ФП принимающим узлом, отправляющий узел удаляет файлы пакета-подтверждения и ФП (который был усечен до нулевой длины принимающим узлом).

Файловый транспорт

Данный транспорт реализует пересылку пакетов между узлами локальной сети Windows. Помимо универсального параметра interval, транспорт имеет следующие частные параметры.

  • outpath (Исходящие): полный путь к каталогу, в который помещаются исходящие конверты, направляемые соответствующей удаленной базы данных;
  • inpath (Входящие): полный путь к каталогу для размещения входящих конвертов, которые помещаются туда транспортом, работающим в удаленной базе.

Очевидно, что для двух баз А и Б, взаимодействующих с помощью файлового транспорта, каталог outpath базы А должен указавать на каталог inpath базы Б, и наоборот. Оба каталога должны быть доступы по чтению и записи пользователю, учетная запись которого используется при запуске службы SMPost (подробнее см. раздел «Особенности настройки службы почтового сервера Супермага» в документе «Сервер Супермага.doc»). В частности, учетная запись LocalSystem, используемая по умолчанию, обычно не имеет доступа к каталогам на удаленных компьютерах.
Для задания путевых имен рекомендуется использовать UNC-пути в формате \\server\share\path. Использование путей, начинающихся с буквы диска, не рекомендуется, но допускается.
Каталоги обмена могут быть размещены как локально, так и удаленно. Однако, для повышения производительности рекомендуется, чтобы каталог inpath был локальным.

Транспорт FTP

Данный транспорт осуществляет пересылку конвертов по стандартному протоколу FTP. Помимо универсального параметра interval, транспорт имеет следующие частные параметры:

  • host (Сервер): адрес ftp-сервера (например, someserver.servplus.ru);
  • user (Пользователь): имя пользователя для доступа к ftp-серверу; если сервер поддерживает только анонимный доступ, используйте anonymous; однако, у пользователя должны быть права на создание и удаление файлов в каталогах outpath и inpath;
  • pwd (Пароль): пароль доступа к к ftp-серверу (пароль хранится в базе данных в зашифрованном виде); в случае анонимного доступа строка может быть произвольной (пустая строка не допускается); в любом случае, пароли, передаются по протоколу FTP нешифрованными;
  • outpath (Исходящие): путь к каталогу на ftp-сервере, в который помещаются исходящие конверты, направляемые соответствующей удаленной базы данных;
  • inpath (Входящие): путь к каталогу на ftp-сервере для размещения входящих конвертов, которые помещаются туда транспортом, работающим в удаленной базе;
  • passive (Пассивный): если установлен (по умолчанию), то используется пассивный FTP.


Транспорт E-mail

Данный транспорт осуществляет отправку конвертов по протоколу SMTP и конвертов пакетов, поступающих на сервер электронной почты, поддерживающий протокол POP3. Помимо универсального параметра interval, транспорт имеет следующие универсальные параметры:

  • inbox (Адрес): адрес почтового ящика для входящих сообщений (например somesmpost@servplus.ru) на сервере POP3;
  • smtpserver (SMTP-сервер): URL сервера исходящих сообщений (SMTP);
  • smtpport (SMTP-порт): порт сервера исходящих сообщений (по умолчанию 25);
  • smtptimeout (SMTP-таймаут (сек)): тайм-аут сервера исходящих сообщений в секундах;
  • smtpuser (SMTP-пользователь): имя пользователя для доступа к серверу исходящих сообщений; если равен '*', то доступ к SMTP-серверу осуществляется анонимно и smtppwd игнорируется;
  • smtppwd (SMTP-пароль) : пароль доступа к серверу исходящих сообщений (пароль хранится в базе данных в зашифрованном виде);
  • pop3server (POP3-сервер): сервер входящих сообщений (POP3), предоставляющий доступ к почтовому ящику inbox;
  • pop3port (POP3-порт): порт сервера входящих сообщений (по умолчанию 110);
  • pop3user (POP3-пользователь): имя пользователя для доступа к серверу исходящих сообщений;
  • pop3pwd (POP3-пароль): пароль доступа к серверу входящих (пароль хранится в базе данных в зашифрованном виде).
  • pop3timeout (POP3-таймаут (сек)): тайм-аут сервера входящих сообщений в секундах.

Частные параметры транспорта:

  • remoteaddr (Адрес): адрес удаленной базы данных. По этому адресу осуществляется отправка исходящих сообщений и он должен быть указан в качестве адреса отправителя входящих сообщений.

Дозвон

Для всех встроенных транспортов, кроме транспорта прямого обмена, почтовый модуль поддерживает установление соединений по коммутируемым линиям посредством модемов (дозвон). Для реализации автоматического дозвона необходимо установить модем и настроить одно или несколько модемных соденений. Настройка соединений осуществляется средствами ОС (в Windows 2000: папка «Network and Dial-up Connections», пункт контекстного меню «New connection..». Вы можете настоить соединение как для подключения к Интернет-провайдеру, так и для непосредственного доступа к удаленному компьютеру, на котором установлен сервер удаленного доступа (Windows RAS).
Задав параметры соединения необходимо хотя бы один раз успешно установить его вручную, задав при этом флажок «запоминать пароль» в соответствующем диалоге операционной системы, если пароль необходим. В тех случаях, когда удаленный сервер использует для интегрированную аутентификацию Windows NT, на этом сервере должны быть предоставлены права удаленного доступа пользователю, учетная запись которого используется для запуска сервиса SMPost.
После настройки соединения необходимо указать использование данного соединения при выполнении обмена с удаленными базами SMPost. Соединение задается для каждой удаленной базы, причем несколько баз могут работать посредством одного и того же соединения. Попытка установки соединения будет осуществляться при каждой попытке активизации транспорта.
Параметры для осуществления дозвона определены для всех внутренних транспортов, кроме транспорта прямого обмена:

  • dialup (Модемное соединение): название модемного соединения, как оно отображается в папке «Network and Dial-Up Connections». Регистр букв не имеет значения; если значение параметра не задано (установка по умолчанию), то считается, что необходимое для работы транспорта соединение устанавливается извне (например, для связи используется локальная сеть);
  • hangup (Вешать трубку): если установлен (по умолчанию), то соединение автоматически разрывается по окончании работы транспорта; если для разных удаленных баз данных этот параметр имеет разное значение, то при одновременной активизации транспортов для этих баз соединение разрываться не будет. Если данный флажок установлен, то соединение будет разорвано даже в том случае, если оно уже было установлено на момент активизации транспорта.

Режимы пересылки пакетов

ПМ Супермаг 2000 поддерживает следующие режимы пересылки пакетов:

  • нормальный;
  • без фильтрации:
  • непосредственный;
  • прямой.


Нормальный режим описан выше. Отправляющая сторона преобразует с помощью соответствующего фильтра ВП в ФП. Затем ФП помещается в каталог исходящих сообщений и пересылается на удаленный узел средствами транспорта ТП. Удаленный узел обрабатывает полученный ФП и возвращает пакет-подтверждение, который помещается средствми ТП в соответствующий каталог входящих сообщений.
В режиме «без фильтрации» фильтр типа базы данных не используется. ФП создается в соответствующем каталоге исходящих сообщений путем простого копирования ВП (с переименованием). Принимающая сторона должна быть способна обработать ФП, который фактически является ВП, т.е. также без применения фильтра. После обработки полученного ВП пакет-подтверждение возвращается обычным способом.
Непосредственный режим возможен в том случае, когда каталоги исходящих и входящих сообщений доступны обеим узлам непосредственно, т.е. ТП не используется. Два узла, взаимодействующие в непосредственном режиме, должны быть сконфигурированы так, что каталог исходящих сообщений узла 2 на узле 1 соответствует каталогу входящих сообщений узла 1 на узле 2. Аналогично должен быть сконфигурирован каталог исходящих сообщений. В непосредственном режиме принимающий узел не удаляет ФП после его обработки, но усекает файл пакета до нулевого размера. Это позволяет избежать повторных попыток пересылки ФП отправляющим узлом. Пакет-подтверждение помещается принимающим узлом в каталог исходящих сообщений отправляющего узла, который для последнего является каталогом входящих сообщений первого. Получив сообщений об успешном приеме ФП принимающим узлом, отправляющий узел удаляет файлы пакета-подтверждения и ФП (который был усечен до нулевой длины принимающим узлом).
Прямой режим пересылки является наиболее эффективным и представляет собой сочетание режимов «непосредственный» и «без фильтрации». Т.е. в этом режиме осуществляет непосредственный обмен ФП без использования фильтра — непосредственный обмен ВП.
По умолчанию используется нормальный режим пересылки. Обе стороны должны быть настроены на один и тот же режим пересылки. В противном случае результаты работы ПМ не определены. Кроме того, в непосредственном режиме должны быть правильно настроены каталоги входящих и исходящих сообщений.
ПМ Супермаг 2000 может одновременно использовать разные режимы пересылки для разных узлов.

Алгоритм автоматической генерации заказа.


Основные термины.


Соглашение о поставках – документ «Соглашение о поставках» в статусе «Принят» с типом контракта не «Дополнительный», у которого дата окончания не установлена или не меньше текущей даты, а дата начала заказа (или дата начала контракта, если дата начала заказа в документе не задана) не больше даты создаваемого заказа. Под датой создаваемого заказа понимается значение опции «Только на дату», если она выбрана пользователем в диалоге запуска генерации заказа, или текущая дата, если эта опция не выбрана. Также для артикула проверяется, что значение поля «Дата начала заказа» из спецификации соглашения о поставках не задано или не больше даты создаваемого заказа.
Действующее обязательство склада – обязательство склада в статусе «Принят», у которого период действия включает текущую дату.
Распределительный центр (РЦ) - место хранения, для которого формируется заказ.
Акция (документ изменения спроса) – документ «Прогноз изменения спроса» в статусе «Принят» или документ «Маркетинговая акция» в статусе «Исполняется», «Завершена» или «Принята» (если в расчете нужно учитывать еще не начавшиеся акции). Если в завершенных акциях заполнены фактические коэффициенты спроса, то в расчётах будут использованы именно они.
Дата начала акции – дата начала изменения спроса из документа «Прогноз изменения спроса» или планируемая дата начала акции (без учёта времени) из документа «Маркетинговая акция».
Дата окончания акции – дата окончания изменения спроса из документа «Прогноз изменения спроса» или фактическая дата окончания акции (без учёта времени) из документа «Маркетинговая акция». Если для маркетинговой акции фактическая дата окончания не установлена, то берётся планируемая дата окончания акции (без учёта времени).
Среднесуточная реализация (ССР) (Дневной расход, Скорость продаж) – раздел «Карточки складского учета», вкладка «Заказ», колонка «Среднесуточная реализация». Если для артикула установлен признак «Заказ без учета с/с реализации», его ССР всегда принимается равной нулю.
Если в диалоге запуска генерации заказа выбрана опция «С учётом документов изменения спроса», то ССР из карточки товара для дальнейшего расчёта подвергается коррекции в зависимости от типа влияния документов изменения спроса на расчёт ССР. Этот параметр сохраняется в карточке товара одновременно с сохранением ССР, полученной в ходе последнего расчёта.
Внимание! Для алгоритма Fresh опция «С учётом документов изменения спроса» игнорируются полностью здесь и далее.
Если при расчёте ССР не был установлен параметр «Влияние документов изменения спроса: С учётом коэффициентов изменения спроса», то:
Если для ССР в карточке не установлен признак «ССР посчитана в период изменения спроса», а на текущую дату имеется действующая акция,
[ССР] = [ССР из карточки товара] * [К1 спроса начала];
Если для ССР в карточке установлен признак «ССР посчитана в период изменения спроса», а на текущую дату нет действующей акции, то при наличии завершенной маркетинговой акции с датой окончания меньше текущей даты или равной ей или при наличии прогноза изменения спроса с датой окончания меньше текущей даты,
[ССР] = [ССР из карточки товара] * [К2 спроса конца] / [К1 спроса начала];
Величина ССР, используемая для расчета, будет меняться в даты начала / окончания акций, если эти даты больше текущей даты. Начиная с даты начала акции [ССР] = [ССР предыдущей даты] * [К1 спроса начала]. Начиная с даты, следующей после даты окончания акции, [ССР] = [ССР даты окончания акции] * [К2 спроса конца] / [К1 спроса начала]. Если в какие-либо даты начиналось или заканчивалось несколько акций, то будет рассмотрено влияние только одной акции.
Например, текущая дата 02 марта, ССР из карточки 10 штук. Ближайшая маркетинговая акция в статусе «Принята»:
03 марта – 05 марта, [К1] = 1.5, [К2] = 0.8.
Тогда для расчетов будут использоваться следующие значения ССР:
02 марта10 штук
03 марта10 * 1.5 = 15 штук
04 марта10 * 1.5 = 15 штук
05 марта10 * 1.5 = 15 штук
06 марта и далее до следующей даты изменения ССР15 * [0.8 / 1.5] = 8 штук
Если при расчёте ССР был установлен параметр «Влияние документов изменения спроса: С учётом коэффициентов изменения спроса», то:
Величина ССР, используемая для расчета, будет меняться в даты начала / окончания акций. Рассматриваются даты начала / окончания акций больше последней даты периода расчета ССР, которая сохраняется в карточке товара одновременно со значением ССР.
Начиная с даты начала акции [ССР] = [ССР предыдущей даты] * [К1 спроса начала].
Начиная с даты, следующей после даты окончания акции, [ССР] = [ССР даты окончания акции] * [К2 спроса конца] / [К1 спроса начала].
Все такие акции влияют совокупно, то есть коэффициенты, изменяющие ССР, перемножаются.
Например, дата расчета ССР 02 марта, ССР из карточки 10 штук. В это время были и будут акции:
02 марта – 03 марта – акция [K1] = 1.5, [K2] = 0.8;
04 марта – 05 марта – акция [K1] = 1.1, [K2] = 0.9.
Тогда реализация будет откорректирована следующим образом:
02 марта 10 * 1.5 = 15 штук
03 марта 15 штук
04 марта 15 * [0.8 / 1.5] * 1.1 = 8.8 штук
05 марта 8.8 штук
06 марта и далее до следующей даты изменения ССР 8.8 * [0.9 / 1.1] = 7.2 штук

Средняя ССР – сумма ССР по дням недели, деленная на 7.
Остаток на конец даты Д2 – расчётная величина, которая при неизменном за период дневном расходе = [Остаток на конец даты Д1] - [ССР] * ( [Д2] – [Д1] ). Если ССР в период с (Д1+1) по Д2 менялась, то остаток считается с учетом всех значений ССР по дням.
Минимальный уровень складских запасов - раздел «Карточки складского учета», вкладка «Заказ», поле «Мин.» + поле «Зал».
Если в диалоге запуска генерации заказа выбрана опция «С учётом документов изменения спроса» и для места хранения установлен признак «Уровень торговых запасов минимальный: в днях торговли», то:

  • если для ССР в карточке установлен признак «Среднесуточная реализация посчитана в период изменения спроса», а на текущую дату нет действующей акции, то при наличии завершенной акции с датой окончания меньше текущей даты или равной ей, [Минимальный уровень складских запасов] = [Минимальный уровень складских запасов] * [К2 спроса конца завершенной акции] / [К1 спроса начала завершенной акции].
    Максимальный уровень складских запасов - раздел «Карточки складского учета», вкладка «Заказ», поле «Макс.» + поле «Зал». Если значение поля «Макс.» не указано, максимальный уровень складских запасов считается не заданным, даже если значение «Зал» задано. Для алгоритма «РЦ минимальный» максимальный уровень принимается = мин. уровню.
    Размер упаковки – поле «Раздел упаковки» из действующего соглашения о поставках.
    Дочерние места хранения РЦ – если РЦ – не локальный склад: это места хранения, подчиненные РЦ или его дочерним местам хранения; если РЦ – локальный склад: это места поставки действующих обязательств РЦ и их подчиненные МХ. Дополнительно дочерние места хранения должны отвечать условиям:

  • Включен признак «Оприходован».
  • Приоритет больше или равен 0.
  • Не относится к типу «Склад возврата» или «Склад брака».
  • Текущий артикул входит в номенклатуру данного места хранения.
  • Для данного места хранения нет соглашений о поставках.
  • Макс. уровень складских запасов текущего артикула > 0 или не установлен.
  • Если РЦ – не локальный склад: данное место хранения не является местом поставки действующего обязательства склада, который не снабжается с текущего РЦ (т.е. не отвечает всем признакам «дочернего места хранения»).


Общая схема (последнее изменение: 1.57 sp2)

Формирование заказа для текущего артикула для РЦ по алгоритму, выбранному в диалоге запуска генерации заказа:
Алгоритм заказа «Стандартный».,
Алгоритм заказа «Fresh».,
Алгоритм заказа «РЦ избыточный» / «РЦ минимальный».08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400300031003900390037000000 ,
Алгоритм заказа «РЦ в упаковках для магазинов».08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003300360038003900300035003900340035000000
Если в диалоге запуска генерации заказа была выбрана опция «Только на дату», то документы будут созданы только для заказов на указанную дату.
Если предложение заказа для артикула из соглашения о поставках меньше значения поля «Мин. кол-во заказа» из спецификации этого соглашения о поставках, то заказ для данного артикула сформирован не будет.
Список распределительных центров.08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400300031003100320036000000
Для текущего РЦ: Список артикулов.08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400300031003100360034000000

Для текущего артикула и РЦ: Список соглашений о поставках.


Добавление зависимых компонентов набора в заказ в количестве равном количеству основного компонента. Под основным компонентом понимается первый из перечисленных в наборе компонентов, который не является зависимым компонентом.
Если суммарное предложение заказа по всем артикулам из соглашения о поставках меньше значения поля «Мин. кол-во» из заголовка этого соглашения о поставках, то заказ сформирован не будет.



















Список распределительных центров.


1) Отбор в диалоге запуска генерации заказа:
Генерация заказов по выбранным соглашениям о поставках: рассматриваются выбранные пользователем места поставки из выбранных соглашений о поставках.
или
Генерация заказов по местам хранения: рассматриваются выбранные пользователем места хранения.
2) Отбор в процедуре генерации заказа мест хранения, отвечающих условиям:

  • Включен признак «Оприходован».
  • Отключен признак «Отключить автогенерацию заказов».
  • Тип «Центральный склад», «Склад», «Склад-магазин».


Список артикулов.


1) Отбор в диалоге запуска генерации заказа:

  • Только выбранные группы товаров.


2) Отбор в процедуре генерации заказа артикулов, отвечающих условиям:

  • Статус карточки складского учета «активна».
  • Установлен признак «прием разрешен».
  • Если заказ по выбранным соглашениям о поставках: артикул входит в выбранные пользователем соглашения о поставках для РЦ.
  • Если заказ не по выбранным соглашениям о поставках и в диалоге запуска генерации заказа выбран поставщик: артикул входит в соглашение о поставках с выбранным поставщиком.
  • Если заказ не по выбранным соглашениям о поставках и в диалоге запуска генерации заказа не выбран поставщик: артикул входит в соглашения о поставках с поставщиками, разрешенными текущему пользователю.
  • Артикул не является зависимым компонентом набора («залоговой тарой»).
  • Если РЦ - не центральный склад, максимальный уровень складских запасов артикула в РЦ отличен от нуля или не установлен.
  • Если РЦ - не центральный склад, то артикул входит в номенклатуру РЦ.


Список соглашений о поставках.


Условия заказа и поставки на РЦ артикула берутся из соглашения о поставках.
Если установлена опция «по выбранным соглашениям о поставках»: будут рассмотрены выбранные пользователем соглашения. Если дополнительно выбрана опция «С учётом маркетинговых соглашений…», то в перечень рассматриваемых соглашений будут добавлены соглашения, созданные на основании маркетинговых контрактов, в общих основаниях которых указаны основные контракты выбранных пользователем соглашений. При этом места поставок и список артикулов будут определяться только выбранными пользователем соглашениями. Если в добавленном маркетинговом соглашении будут артикулы, отсутствующие в основном соглашении, то заказ для них сформирован не будет.
Если не установлена опция «по выбранным соглашениям о поставках», но выбраны поставщики или группы поставщиков: будут рассмотрены соглашения для выбранных пользователем поставщиков.
Если не установлена опция «по выбранным соглашениям о поставках» и не выбраны поставщики: будут рассмотрены соглашения для разрешенных текущему сотруднику поставщиков.

Выбор лучшего соглашения для алгоритма «Стандартный» / «Fresh» / «РЦ в упаковках для магазинов».


Последовательно выполняется несколько шагов, на которых сравниваются параметры соглашений. Если на каком-то шаге делается вывод о том, что ранее выбранное или текущее соглашение является лучшим, то последующие шаги не выполняются.

  1. Если соглашение первое из списка, оно становится лучшим.

  2. Для ранее выбранного поставщика установлена проверка цен контракта на дату поставки / отгрузки и [Дата ближайшей поставки] ранее выбранного соглашения не входит в период его действия. Для текущего поставщика не установлена проверка цен контракта на дату поставки / отгрузки или [Дата ближайшей поставки] текущего соглашения входит в период его действия. Текущее соглашение становится лучшим.

  3. Для текущего поставщика установлена проверка цен контракта на дату поставки / отгрузки и [Дата ближайшей поставки] текущего соглашения не входит в период его действия. Для ранее выбранного поставщика не установлена проверка цен контракта на дату поставки / отгрузки или [Дата ближайшей поставки] ранее выбранного соглашения входит в период его действия. Лучшим остаётся ранее выбранное соглашение.

  4. Текущее соглашение является маркетинговым. Ранее выбранное соглашение является основным. Текущее соглашение становится лучшим.
  5. Текущее соглашение является основным. Ранее выбранное соглашение является маркетинговым. Лучшим остаётся ранее выбранное соглашение.

  6. [Дата ближайшей готовности к продаже] текущего соглашения и ранее выбранного соглашения либо обе больше, либо обе меньше [Дата, когда остаток снизится ниже минимума]. [Дата ближайшей готовности к продаже] текущего соглашения ближе к [Дата, когда остаток снизится ниже минимума], чем у ранее выбранного соглашения. Текущее соглашение становится лучшим.

  7. [Дата ближайшей готовности к продаже] текущего соглашения меньше [Дата, когда остаток снизится ниже минимума]. [Дата ближайшей готовности к продаже] ранее выбранного соглашения больше [Дата, когда остаток снизится ниже минимума]. Текущее соглашение становится лучшим.

  8. [Цена без налогов] из контракта с поставщиком текущего соглашения меньше, чем у ранее выбранного соглашения или у ранее выбранного соглашения цена не определена. Текущее соглашение становится лучшим.

  9. Лучшим остается ранее выбранное соглашение.




Выбор лучшего соглашения для алгоритмов «РЦ избыточный» / «РЦ минимальный».


Последовательно выполняется несколько шагов, на которых сравниваются параметры соглашений. Если на каком-то шаге делается вывод о том, что ранее выбранное или текущее соглашение является лучшим, то последующие шаги не выполняются.

  1. Если соглашение первое из списка, оно становится лучшим.

  2. Для ранее выбранного поставщика установлена проверка цен контракта на дату поставки / отгрузки и [Дата ближайшей поставки] ранее выбранного соглашения не входит в период его действия. Для текущего поставщика не установлена проверка цен контракта на дату поставки / отгрузки или [Дата ближайшей поставки] текущего соглашения входит в период его действия. Текущее соглашение становится лучшим.

  3. Для текущего поставщика установлена проверка цен контракта на дату поставки / отгрузки и [Дата ближайшей поставки] текущего соглашения не входит в период его действия. Для ранее выбранного поставщика не установлена проверка цен контракта на дату поставки / отгрузки или [Дата ближайшей поставки] ранее выбранного соглашения входит в период его действия. Лучшим остаётся ранее выбранное соглашение.

  4. Текущее соглашение является маркетинговым. Ранее выбранное соглашение является основным. Текущее соглашение становится лучшим.
  5. Текущее соглашение является основным. Ранее выбранное соглашение является маркетинговым. Лучшим остаётся ранее выбранное соглашение.

  6. [Дата ближайшей готовности к продаже] текущего соглашения меньше [Дата ближайшей готовности к продаже] ранее выбранного соглашения. Текущее соглашение становится лучшим.

  7. [Дата ближайшей готовности к продаже] ранее выбранного соглашения меньше [Дата ближайшей готовности к продаже] текущего соглашения. Лучшим остаётся ранее выбранное соглашение.

  8. [Цена без налогов] из контракта с поставщиком текущего соглашения меньше, чем у ранее выбранного соглашения или у ранее выбранного соглашения цена не определена. Текущее соглашение становится лучшим.

  9. Лучшим остается ранее выбранное соглашение.



Алгоритм заказа «Стандартный».

да
нет
[Дата, когда остаток снизится ниже минимума] определена
Заказ для текущего артикула сформирован не будет.
[Поиск: [Дата, когда остаток снизится ниже минимума] для алгоритмов «Стандартный» / «РЦ в упаковках для магазинов».|C:\TEMP\3\1\Алгоритм автоматической генерации заказа.doc#Поиск: [Дата, когда остаток снизится ниже минимума] для алгоритмов «Стандартный» / «РЦ в упаковках для магазинов».]
Выбор соглашения о поставках.08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400350038003100330038000000
да
нет
Соглашение о поставках выбрано
Будет сформирован заказ для текущего артикула в размере [Кол-во заказ].
Для текущего артикула заказ сформирован не будет.
да
нет
Если МХ – РЦ, то [Остаток на день ближайшей поставки]
= [Текущие остатки РЦ. Поставка]
[Срок реализации] не установлен или больше 1.
[Остаток на день ближайшей поставки]
= [Остаток на день ближайшей поставки] + [Остаток МХ]
[ССР] = [ССР] + [ССР МХ]
[Минимальный уровень] = [Минимальный уровень] + [Минимальный уровень МХ]
[Максимальный уровень] = [Максимальный уровень] + [Максимальный уровень МХ]
Первое место хранения из списка мест хранения (РЦ + дочерние МХ) ).
[Остаток на день ближайшей поставки] = 0
Переход к следующему месту хранения из списка.
[Остаток МХ] = [Текущие остатки МХ. Оперативный остаток] - [Текущие остатки МХ. Потери]. Отрицательное значение обнуляется.
МХ - РЦ
да
нет
[Остаток МХ] = [Остаток МХ] + [Текущие остатки МХ. Поставка]





































































Алгоритм заказа «Fresh».

да
нет
[Дата, когда остаток снизится ниже минимума] определена
Заказ для текущего артикула сформирован не будет.
[Поиск: [Дата, когда остаток снизится ниже минимума] для алгоритма «Fresh».|C:\TEMP\3\1\Алгоритм автоматической генерации заказа.doc#Поиск: [Дата, когда остаток снизится ниже минимума] для алгоритма «Fresh».]
Выбор соглашения о поставках.08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400350038003100330038000000
да
нет
Соглашение о поставках выбрано
Будет сформирован заказ для текущего артикула в размере [Кол-во заказ].
Для текущего артикула заказ сформирован не будет.
да
нет
Если МХ – РЦ, то [Остаток на день ближайшей поставки]
= [Текущие остатки РЦ. Поставка]
[Срок реализации] не установлен или больше 1.
[Остаток МХ] = [Текущие остатки МХ. Остаток] - [Текущие остатки МХ. Потери]. Отрицательное значение обнуляется.
[ССР] = [ССР] + [ССР МХ] (для каждого дня недели подсчет ведется отдельно)
[Минимальный уровень] = [Минимальный уровень] + [Минимальный уровень МХ]
[Максимальный уровень] = [Максимальный уровень] + [Максимальный уровень МХ]
Первое место хранения из списка мест хранения (РЦ + дочерние МХ).
[Остаток на день ближайшей поставки] = 0
Переход к следующему месту хранения из списка.
МХ - РЦ
да
нет
[Остаток МХ] = [Остаток МХ] + [Текущие остатки МХ. Поставка]
[Остаток МХ] = [Остаток МХ] – [Кол-во приходов] + [Кол-во расходов]. Приходы и расходы берутся из документов товародвижения за текущий день в статусах «Принят в количестве» и «Принят в количестве и ценах». Из рассмотрения исключены накладные с операцией «Приход».
[Остаток МХ] = [Остаток МХ] – [ССР МХ для текущего дня недели]
[Остаток на день ближайшей поставки]
= [Остаток на день ближайшей поставки] + [Остаток МХ]

































































Поиск количества заказа для алгоритма «Стандартный».


[Остаток на день ближайшей поставки] = [Остаток на день ближайшей поставки] – [Сумма ССР за период с Д1+1 по Д2], где [Д1] = [Текущая дата], [Д2] = [Дата ближайшей готовности к продаже]. Если получилась отрицательная величина, она обнуляется.
[Остаток на день следующей поставки] = [Остаток на день ближайшей поставки] - [Сумма ССР за период с Д1+1 по Д2], где [Д1] =
[Дата ближайшей готовности к продаже], [Д2] = [Дата ближайшей готовности к продаже] + [Интервал между поставками]
[Кол-во заказа] = [Мин. уровень] - [Остаток на день следующей поставки]
да
нет
[Размер упаковки] > 0
[Кол-во заказа] = [Размер упаковки] * округленное в большую сторону отношение ( [Кол-во заказа] / [Размер упаковки] )
[Кол-во заказа], округленное до точности единицы измерения артикула
да
нет
[ССР] = 0
[Кол-во заказа]
= [Макс. уровень] (или [Мин. уровень], если [Макс. уровень] не задан)
– [Остаток на день ближайшей поставки]
да
нет
[Срок реализации] текущего артикула не установлен или больше 1.
[Кол-во заказа]
= [ССР]
[Остаток на день ближайшей поставки] = 0
[Интервал между поставками]
= [Дата следующей готовности к продаже]

  • [Дата ближайшей готовности к продаже]
    да
    нет
    [Срок реализации] установлен и меньше [Интервал между поставками]
    [Интервал между поставками] = [Срок реализации]



































































Поиск количества заказа для алгоритма «Fresh».


[Остаток на день ближайшей поставки] = [Остаток на день ближайшей поставки] - [Сумма ССР за период с Д1+1 по Д2], где [Д1] = [Текущая дата], [Д2] = [Дата ближайшей готовности к продаже]. Если получилась отрицательная величина, она обнуляется.
[Остаток на день следующей поставки] = [Остаток на день ближайшей поставки] - [Сумма ССР за период с Д1+1 по Д2], где [Д1] = [Дата ближайшей готовности к продаже], [Д2] = [Дата ближайшей готовности к продаже] + [Интервал между поставками]
[Кол-во заказа] = [Мин. уровень] - [Остаток на день следующей поставки]
да
нет
[Размер упаковки] > 0
[Кол-во заказа] = [Размер упаковки] * округленное в большую сторону отношение ( [Кол-во заказа] / [Размер упаковки] )
[Кол-во заказа], округленное до точности единицы измерения артикулада
нет
[Средняя ССР] = 0
[Кол-во заказа]
= [Макс. уровень] (или [Мин. уровень], если [Макс. уровень] не задан)
– [Остаток на день ближайшей поставки]
да
нет
[Срок реализации] текущего артикула не установлен или больше 1.
[Кол-во заказа] = [ССР за день недели, на который приходится дата ближайшей готовности к продаже]
[Остаток на день ближайшей поставки] = 0
[Интервал между поставками]
= [Дата следующей готовности к продаже]

  • [Дата ближайшей готовности к продаже]
    да
    нет
    [Срок реализации] установлен и меньше [Интервал между поставками]
    [Интервал между поставками] = [Срок реализации]



































































Алгоритм заказа «РЦ избыточный» / «РЦ минимальный».

Для текущего артикула заказ сформирован не будет.

[Кол-во заказа], округленное до точности единицы измерения артикула
да
нет
[Кол-во заказа] > 0
Для выбранного поставщика будет сформирован заказ для текущего артикула в размере [Кол-во заказ].
да
нет
[Кол-во заказа] > 0
да
нет
[Размер упаковки] > 0
[Кол-во заказа] = [Размер упаковки] * округленное по математическим правилам отношение ( [Кол-во заказа] / [Размер упаковки] )
Если получившееся [Кол-во заказа] = 0 и ([Остаток дочерних МХ на день ближайшей поставки] < [Мин. уровень дочерних МХ] или [Остаток дочерних МХ на день следующей поставки] <= 0), [Кол-во заказа] = [Размер упаковки]
Выбор соглашения о поставках.08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400350038003100330038000000
да
нет
Соглашение о поставках выбрано
Поиск для алгоритмов «РЦ избыточный» / «РЦ минимальный»: [Остаток на день ближайшей / следующей поставки РЦ], [Остаток дочерних МХ на день ближайшей / следующей поставки], [Потребность дочерних МХ на день ближайшей поставки], [Кол-во заказа], [Мин. уровень дочерних МХ].08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400360032003000360032000000
[Остаток на день следующей поставки РЦ]
= [Остаток на день следующей поставки РЦ]
– ( наименьшее значение из:
[Остаток на день ближайшей поставки РЦ]
и [Потребность дочерних МХ на день ближайшей поставки] )
[Избыточный резерв]
= наименьшее значение из:
[Остаток дочерних МХ на день ближайшей поставки]
и [Избыточный резерв]. Отрицательное значение обнуляется.
[Кол-во заказа]
= [Кол-во заказа]
+ [Избыточный резерв]

  • [Остаток на день следующей поставки РЦ]












































<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="e5516540-40ed-45fb-9dfe-537ace9911ca"><ac:parameter ac:name="">_Ref100462062</ac:parameter></ac:structured-macro>Поиск для алгоритмов «РЦ избыточный» / «РЦ минимальный»: [Остаток на день ближайшей / следующей поставки РЦ], [Остаток дочерних МХ на день ближайшей / следующей поставки], [Потребность дочерних МХ на день ближайшей поставки], [Кол-во заказа], [Мин. уровень дочерних МХ].

Первое место хранения из списка мест хранения (РЦ + дочерние МХ).
да
нет
[Срок реализации] не установлен или больше 1
[Остаток МХ] = [Текущие остатки МХ. Поставка] +
( ([Текущие остатки МХ. Оперативный остаток]

  • [Текущие остатки МХ. Потери]) (отрицательное значение обнуляется) )
    [Остаток на день ближайшей поставки МХ] = [Остаток на конец даты Д2], где [Д1] = [Текущая дата], [Остаток на конец Д1] = [Остаток МХ], [Д2] = [Дата ближайшей готовности к продаже]
    [Остаток на день следующей поставки МХ] = [Остаток на конец даты Д2], где [Д1] = [Дата ближайшей готовности к продаже], [Остаток на конец Д1] = [Остаток на день ближайшей поставки МХ] (отрицательное значение обнуляется), [Д2] = [Дата следующей готовности к продаже]
    [Остаток на день ближайшей поставки МХ] = 0
    [Остаток на день следующей поставки МХ] = [Текущие остатки МХ. Поставка]
    да
    нет
    да
    [Остаток на день следующей поставки МХ] < [Мин. уровень]
    [Потребность МХ на день следующей поставки] = [Макс. уровень] (если не определен, то берется [Мин. уровень]) – [Остаток на день следующей поставки МХ]
    [Кол-во заказа] = [Кол-во заказа] + [Потребность МХ на день следующей поставки]
    [Остаток дочерних МХ на день ближайшей поставки] = [Остаток дочерних МХ на день ближайшей поставки] + [Остаток на день ближайшей поставки МХ]
    [Остаток дочерних МХ на день следующей поставки] = [Остаток дочерних МХ на день следующей поставки] + [Остаток на день следующей поставки МХ]
    Если [Остаток на день ближайшей поставки МХ] < 0:
    [Потребность дочерних МХ на день ближайшей поставки] = [Потребность дочерних МХ на день ближайшей поставки] + [Остаток на день ближайшей поставки МХ (по модулю)]
    [Мин. уровень дочерних МХ] = [Мин. уровень дочерних МХ] + [Мин. уровень]
    нет
    МХ - РЦ
    [Остаток на день ближайшей поставки РЦ] = [Остаток на день ближайшей поставки МХ] – [Текущие остатки РЦ. Резерв]. Отрицательное значение обнуляется.
    [Остаток на день следующей поставки РЦ] = [Остаток на день следующей поставки МХ] - [Текущие остатки РЦ. Резерв]. Отрицательное значение обнуляется.
    [Остаток на день следующей поставки РЦ] = [Остаток на день следующей поставки РЦ] - [Макс. уровень РЦ] (или [Мин. уровень РЦ], если [Макс. уровень РЦ] не задан).
    [Избыточный резерв] = [Текущие остатки РЦ. Резерв] - [Остаток на день ближайшей поставки МХ]
    Переход к следующему месту хранения из списка.


































































Выбор соглашения о поставках.



Первое соглашение из списка соглашений о поставках
Поиск: [Дата ближайшего заказа], [Дата ближайшей поставки], [Дата ближайшей готовности к продаже].08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400350039003700340035000000
Переход к следующему соглашению из списка.
Поиск: [Дата следующего заказа], [Дата следующей поставки], [Дата следующей готовности к продаже].08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400350039003700350033000000
да
нет
Если алгоритм «Стандартный» / «Fresh» / «РЦ в упаковках для магазинов» и [Дата следующей готовности к продаже] <= [Дата, когда остаток снизится ниже минимума]
Текущее соглашение выбывает из рассмотрения.
Выбор лучшего соглашения для алгоритма «Стандартный» / «Fresh» / «РЦ в упаковках для магазинов». Или: Выбор лучшего соглашения для алгоритмов «РЦ избыточный» / «РЦ минимальный».
да
нет
Текущее соглашение стало «лучшим»
Поиск количества заказа для алгоритма «Стандартный».08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400350038003300340030000000 Или: [Поиск количества заказа для алгоритма «Fresh».] Или: Поиск количества заказа для алгоритма «РЦ в упаковках для магазинов»
да
нет
[Кол-во заказа] > 0
Текущее соглашение выбрано для заказа на дату [Дата ближайшего заказа].
да
нет
[Дата ближайшей готовности к продаже] определена
Для текущего артикула заказ сформирован не будет: поставка не нужна.
Дата окончания контракта не установлена или >= [Дата ближайшего заказа]
да
нет
да
нет
Алгоритм «РЦ избыточный» / «РЦ минимальный»



































































<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="7e885272-82ba-4efc-80e6-a3dd536d6f22"><ac:parameter ac:name="">_Ref100459745</ac:parameter></ac:structured-macro>Поиск: [Дата ближайшего заказа], [Дата ближайшей поставки], [Дата ближайшей готовности к продаже].



да
нет
[Частота заказа] > 0
[Дата последнего заказа] = максимальная дата заказа из документов «Заказ поставщику» в статусе «Размещен» или «Закрыт» с установленным флагом «Учитывать при автогенерации заказа» для текущего поставщика. Рассматриваются только заказы за последние три месяца, в общих основаниях которых указано рассматриваемое соглашение о поставках.
[Дата последнего заказа] существует
да
нет
[Дата последнего заказа] >=
[Текущая дата]
да
нет
Заказ для данного поставщика не будет сформирован: заказ уже ожидается.
[Дата последнего заказа]
+ [Частота заказа] > [Текущая дата]
да
нет
[Дата ближайшего заказа] =
[Дата последнего заказа] + [Частота заказа]
[Дата ближайшего заказа] =
[Текущая дата]
Если [Дата ближайшего заказа] не разрешена для заказа, [Дата ближайшего заказа] = ближайшей дате дня недели после [Дата ближайшего заказа], разрешенного для заказа.
[Дата ближайшей поставки] = [Дата ближайшего заказа] + [Срок поставки]
Если [Дата ближайшей поставки] не разрешена для поставки, [Дата ближайшей поставки] = ближайшей дате дня недели после [Дата ближайшей поставки], разрешенного для поставки.
[Дата ближайшей готовности к продаже] = [Дата ближайшей поставки] + наименьшее целое, большее или равное ( [Время обработки на складе] / 24 )

[Дата ближайшего заказа], [Дата ближайшей поставки], [Дата ближайшей готовности к продаже]


































































<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="9a21486a-e112-4e08-992f-fd43c1d0d823"><ac:parameter ac:name="">_Ref100459753</ac:parameter></ac:structured-macro>Поиск: [Дата следующего заказа], [Дата следующей поставки], [Дата следующей готовности к продаже].



да
нет
[Частота заказа] > 0
[Дата следующего заказа]
= [Дата ближайшего заказа]
+ [Частота заказа]
[Дата следующего заказа]
= [Дата ближайшего заказа]
+ 1
Если [Дата следующего заказа] не разрешена для заказа, [Дата следующего заказа] = ближайшей дате дня недели после [Дата следующего заказа], разрешенного для заказа.
[Дата следующей поставки] = [Дата следующего заказа] + [Срок поставки]
Если [Дата следующей поставки] не разрешена для поставки, [Дата следующей поставки] = ближайшей дате дня недели после [Дата следующей поставки], разрешенного для поставки.
[Дата следующей готовности к продаже] = [Дата следующей поставки] + наименьшее целое, большее или равное ( [Время обработки на складе] / 24 )

[Дата следующего заказа], [Дата следующей поставки], [Дата следующей готовности к продаже]


































































Алгоритм заказа «РЦ в упаковках для магазинов».

[Поиск: [Дата, когда остаток снизится ниже минимума] для алгоритма «РЦ в упаковках для магазинов».|C:\TEMP\3\1\Алгоритм автоматической генерации заказа.doc#Поиск: Дата, когда остаток снизится ниже минимума для алгоритма «РЦ в упаковках для магазинов».]

Выбор соглашения о поставках.08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400350038003100330038000000
[Дата, когда остаток снизится ниже минимума] = NULL (не определена)
да
нет
[Дата, когда остаток снизится ниже минимума] определена
Заказ для текущего артикула сформирован не будет.
да
нет
Соглашение о поставках выбрано
Будет сформирован заказ для текущего артикула в размере [Кол-во заказ].
Для текущего артикула заказ сформирован не будет.

<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="ce8d8119-baf4-4332-becc-d2bb29e7347e"><ac:parameter ac:name="">_Ref368666897</ac:parameter></ac:structured-macro> Поиск: [Дата, когда остаток снизится ниже минимума] для алгоритма «РЦ в упаковках для магазинов».

да
нет
[Остаток на день ближайшей поставки МХ]
= 0
[Срок реализации] не установлен или больше 1.
[Остаток на день ближайшей поставки МХ] = ( [Текущие остатки МХ. Поставка] (если МХ – не РЦ, обнуляется ) ) +
( ([Текущие остатки МХ. Оперативный остаток]

  • [Текущие остатки МХ. Потери]) (отрицательное значение обнуляется) )
    Первое место хранения из списка мест хранения (РЦ + дочерние МХ)Переход к следующему месту хранения из списка.
    МХ - РЦ
    да
    нет
    [Остаток на день ближайшей поставки МХ]
    = [Текущие остатки РЦ. Поставка]
    [Поиск: [Дата, когда остаток снизится ниже минимума МХ] для алгоритмов «Стандартный» / «РЦ в упаковках для магазинов».|C:\TEMP\3\1\Алгоритм автоматической генерации заказа.doc#Поиск: [Дата, когда остаток снизится ниже минимума] для алгоритмов «Стандартный» / «РЦ в упаковках для магазинов».]
    [Дата, когда остаток снизится ниже минимума]
    = [Дата, когда остаток снизится ниже минимума МХ]
    да
    нет
    [Дата, когда остаток снизится ниже минимума] не определена или > [Дата, когда остаток снизится ниже минимума МХ]





Поиск количества заказа для алгоритма «РЦ в упаковках для магазинов».

Первое место хранения из списка мест хранения (РЦ + дочерние МХ)
да
нет
[ССР МХ] = 0
[Кол-во заказа МХ] = [Макс. уровень МХ] (или [Мин. уровень МХ], если [Макс. уровень МХ] не задан) – [Остаток на день ближайшей поставки МХ]
да
нет
[Срок реализации] текущего артикула
не установлен
или больше 1.
[Кол-во заказа МХ]
= [ССР МХ]
[Остаток на день ближайшей поставки МХ] = 0
[Интервал между поставками]
= [Дата следующей готовности к продаже]

  • [Дата ближайшей готовности к продаже]
    да
    нет
    [Срок реализации] установлен и меньше [Интервал между поставками]
    [Интервал между поставками] = [Срок реализации]
    [Остаток на день ближайшей поставки МХ] = [Остаток на конец даты Д2], где [Д1] = [Текущая дата], [Остаток на конец Д1] = [Остаток на день ближайшей поставки МХ], [Д2] = [Дата ближайшей готовности к продаже]. Если получилась отрицательная величина, она обнуляется.
    [Остаток на день следующей поставки МХ] = [Остаток на конец даты Д2], где [Д1] = [Дата ближайшей готовности к продаже], [Остаток на конец Д1] = [Остаток на день ближайшей поставки МХ], [Д2] = [Дата ближайшей готовности к продаже] + [Интервал между поставками]
    [Кол-во заказа МХ] = [Мин. уровень МХ] - [Остаток на день следующей поставки МХ]
    да
    нет
    [Размер упаковки] > 0
    [Кол-во заказа МХ] = [Размер упаковки] * округленное по математическим правилам отношение ( [Кол-во заказа МХ] / [Размер упаковки] ).
    Если [Кол-во заказа МХ] = 0 и ([Остаток на день ближайшей поставки МХ] < [Мин. уровень МХ] или [Остаток на день следующей поставки МХ] <= 0), то [Кол-во заказа МХ] = [Размер упаковки]

    [Кол-во заказа] = ( [Кол-во заказа] + [Кол-во заказа МХ] ), округленное до точности единицы измерения артикула.
    Переход к следующему месту хранения из списка.
    да
    нет
    [Кол-во заказа МХ] < 0
    [Кол-во заказа МХ] = - 1 * [Размер упаковки] * округленное в меньшую сторону отношение ( (модуль [Кол-во заказа МХ]) / [Размер упаковки] )
    да
    нет
    [Кол-во заказа МХ] >= 0, или МХ – РЦ,
    или установлена системная опция «Учитывать излишки магазинов при генерации заказов по алгоритму "РЦ в упаковках для магазинов"»
    [Кол-во заказа МХ]
    = 0













































Поиск: [Дата, когда остаток снизится ниже минимума] для алгоритмов «Стандартный» / «РЦ в упаковках для магазинов».


да
нет
[ССР] = 0 и [Остаток на день ближайшей поставки] >= [Минимальный уровень]
[Дата, когда остаток снизится ниже минимума] = NULL
(не определена)
[Дата, когда остаток снизится ниже минимума] = [Текущая дата]
да
нет
[ССР] <> 0 и [Остаток на день ближайшей поставки] > [Минимальный уровень]
[Дата, когда остаток снизится ниже минимума]
= [Дата отсчета]
+ наибольшее целое кол-во дней <=, чем
( [Остаток на конец даты отсчета] - [Минимальный уровень] )
/ [ССР]
[Дата изменения ССР] – ближайшая дата изменения ССР из-за начала / окончания акции, больше чем [Дата отсчета]
да
нет
[Дата изменения ССР] имеется и она <= [Дата, когда остаток снизится ниже минимума]
[Остаток на конец даты отсчета] = [Остаток на конец даты отсчета]
– [ССР]

  • ( [Дата изменения ССР] - 1 – [Дата отсчета] )
    [Дата отсчета] = [Дата изменения ССР] – 1
    [ССР] = новому значению, действующему с [Дата изменения ССР] (алгоритм расчета ССР см. «Основные термины»)
    [Дата отсчета] = [Текущая дата]
    [Остаток на конец даты отсчета] = [Остаток на день ближайшей поставки]
    Расчет завершен
    [Дата, когда остаток снизится ниже минимума] = NULL
    (не определена)
    да
    нет
    [ССР] <> 0
















































Поиск: [Дата, когда остаток снизится ниже минимума] для алгоритма «Fresh».


да
нет
[Средняя ССР] = 0 и [Остаток на день ближайшей поставки] >= [Минимальный уровень]
[Дата, когда остаток снизится ниже минимума] = NULL
(не определена)
[Дата, когда остаток снизится ниже минимума] = [Текущая дата]
да
нет
[Средняя ССР] <> 0 и [Остаток на день ближайшей поставки] > [Минимальный уровень]
[Дата отсчета] = [Дата отсчета] + 1
[Остаток на конец даты отсчета] = [Остаток на конец даты отсчета] – [ССР за день недели, на который приходится дата отсчета]
да
нет
[Остаток на конец даты отсчета] >= [Минимальный уровень]
[Дата отсчета] = [Текущая дата]
[Остаток на конец даты отсчета] = [Остаток на день ближайшей поставки]
Расчет завершен














































Основные термины.


Наценка для артикула – раздел «Карточки складского учета», страница «Цены», поле «Наценка». Если значение поля не установлено, берется значение поля «Наценка на группу».
Шаг цены для артикула – раздел «Карточки складского учета», страница «Цены», поле «Шаг цены». Если значение поля не установлено, берется значение поля «Шаг цены для группы».
Текущая цена артикула – раздел «Карточки складского учета», страница «Цены», поле «Цена» (при условии, что флаг «Маркетинговая цена» не установлен). Если текущая цена – маркетинговая, то в качестве текущей будет взята цена, которая будет установлена актом переоценки завершения маркетинговой акции.
Правила округления – раздел «Цены», страница «Правила округления цены». Описание правил округления см. раздел «Справочники», справочник «Правила округления».
Товар с признаком «государственная фиксированная цена» – товар, для которого флаг позиции спецификации исходной накладной «Регулирование цены» установлен в «государственная фиксированная цена» или «скидка с розничной цены».
Макс. наценка от цены произв. – раздел «Цены», страница «Наценки», значение «Макс. наценка от цены производителя / импортёра, %».
Цена транспортных расходов для позиции спецификации исходной накладной = [Сумма транспортных расходов] / [Количество товара], кроме товаров с признаком «государственная фиксированная цена», для которых это значение = 0.
Цена внутренней транспортировки для позиции спецификации исходной накладной = [Расходы на внутреннюю транспортировку] / [Количество товара], кроме товаров с признаком «государственная фиксированная цена», для которых это значение = 0.
Допустимая торговая надбавка от цены импортёра, %
= (([Макс. наценка от цены произв.] + 100) / 100) / (([Надбавка оптовая / импортёра] + 100) / 100) * 100 - 100
Максимально разрешенная цена без НДС, если не установлен флаг «Импортный товар» = ([Цена производителя / импортёра] + [Цена транспортных расходов]) * (1 + [Макс. наценка от цены произв.] / 100) + [Цена внутренней транспортировки]
Максимально разрешенная цена без НДС, если установлен флаг «Импортный товар» = ([Цена производителя / импортёра] + [Цена транспортных расходов]) * (1 + [Допустимая торговая надбавка от цены импортёра, %] / 100) + [Цена внутренней транспортировки]
Максимально разрешенная цена полная – это [Максимально разрешенная цена без НДС], к которой прибавляются НДС и налоги, следующие в порядке применения после НДС, прикрепленные к артикулу на текущую дату для региона места прихода. Если установлена «Макс. наценка от цены произв.», то максимально разрешенная цена полная округляется в меньшую сторону. Если задано правило округления цены и в нем найдена настройка с максимальным значением «Порог цены», меньшем максимально разрешенной цены полной, максимально разрешенная цена полная округляется в соответствии с найденной настройкой.
При расчёте максимально разрешенной цены предполагается, что в спецификации для каждого артикула будет только одна строка, иначе для расчётов будут взяты максимальные значения каждого параметра среди всех позиций накладной с данным артикулом.



Алгоритм наценивания по приходной накладной (Беларусь)

(последнее изменение: 1.060)


  1. Акты переоценки создаются для каждого вида цены, назначенного месту хранения прихода.


  1. В перечень нацениваемых артикулов добавляются артикулы из исходного документа, если не установлен параметр «Наценивание по свойствам для артикула» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»). Если этот параметр установлен и если в спецификации исходного документа имеются ссылки на активные комплексные артикулы с ненулевым количеством и указанным свойством (поле «Свойство»), то в перечень для наценивания будут включены эти артикулы (см. поле «Арт. ценника»), а не их базовые артикулы из спецификации исходного документа. Прочие артикулы будут включены в перечень обычным образом.


  1. Определение базовой цены для артикулов, для которых в спецификации исходного документа не установлен признак «государственная фиксированная цена». Базовая цена рассчитывается в зависимости от значения параметра «Наценивание от цены производителя»: а) если параметр «Наценивание от цены производителя» не установлен:

  • если оптовая надбавка положительна:
    [Базовая цена] = [Цена производителя] * (1 + [Надбавка оптовая / импортёра]/100) + [Цена транспортных расходов] * (1 + [Надбавка оптовая / импортёра]/100)

  • если оптовая надбавка отрицательна или равна нулю:
    [Базовая цена] = [Цена производителя] * (1 + [Надбавка оптовая / импортёра]/100) + [Цена транспортных расходов]
    б) если параметр «Наценивание от цены производителя» установлен: [Базовая цена] = [Цена производителя] + [Цена транспортных расходов]
    Во всех случаях увеличиваем посчитанную базовую цену на величину расходов на внутреннюю транспортировку:
    [Базовая цена] = [Базовая цена] + [Цена внутренней транспортировки]
    Если в исходном документе несколько строк с одним артикулом, то базовая цена рассчитывается согласно значению параметра «Цена повтор. артикула при наценивании» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»). Если параметр «Наценивание по свойствам для артикула» не установлен и если в спецификации исходного документа есть артикулы с распределением ненулевого количества поставки по свойствам (поле «Свойство»), то базовая цена таких артикулов подвергается коррекции в соответствии со значением «Процент цены поставки» (см. раздел «Свойства для артикулов», страница «Цены поставки»). Т.к. поставщик приходной накладной может поставлять разные значения свойства одного артикула с разными ценами, то базовую цену нужно скорректировать, чтобы при приходе разных значений свойства не менялась цена базового артикула:[Базовая цена] = [Базовая цена] * 100 / [Процент цены поставки]
    Данная функциональность работает корректно при наличии в приходной накладной только одного значения свойства артикула. Иначе в качестве процента цены поставки будет взято максимальное значение процента цены поставки из всех значений встречающихся в приходе свойств.

  1. Определение базовой цены для артикулов, для которых в спецификации исходного документа установлен признак «фиксированная государственная цена». В качестве базовой цены берется цена производителя из спецификации исходного документа. Предполагается, что в спецификации для каждого артикула будет только одна строка, иначе в качестве цены производителя будет взята максимальная цена производителя для данного артикула.


  1. В перечень нацениваемых артикулов добавляются активные комплексные артикулы, созданные на базе артикулов из спецификации исходного документа (если они не были добавлены в перечень для наценивания на шаге 1). При этом:


  • артикулы типа «размер» добавляются только при отключенном параметре «Наценивание по свойствам для артикула»;
  • артикулы типа «уценка» добавляются только при включенном параметре «Наценивать уценочные артикулы».
    Базовая цена для добавленных на этом шаге артикулов не определяется, т.к. их наценивание будет происходить на основе базовых цен их компонентов.
  1. Расчет новой цены для артикулов с положительной розничной ценой из спецификации исходного документа, если вид цены акта переоценки является ценой для кассы места хранения акта. Новая цена устанавливается = розничной цене из исходного документа.


  1. Расчет новой цены для артикулов с флагом «Фиксированная цена» , для которых новая цена не была установлена на шаге 6. Новая цена устанавливается = текущей цене.


  1. Расчет новой цены для артикулов, добавленных на шаге 1, для которых новая цена не была установлена на шагах 6 или 7 и для которых в спецификации накладной установлен признак «фиксированная государственная цена». [Новая цена] = [Базовая цена] К получившейся новой цене прибавляются налоги, следующие в порядке применения после НДС и прикрепленные к артикулу на текущую дату для региона места прихода. Если нацениваемый вид цены не в базовой валюте, новая цена преобразуется в валюту вида цены по курсу из исходного документа. Если в исходном документе курс не установлен, будет взят банковский курс на дату исходного документа. Если новая цена получилась отличной от базовой цены, новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>].


  1. Расчет новой цены для артикулов, добавленных на шаге 1, для которых новая цена не была установлена на шагах 6 или 7 и для которых в спецификации накладной не установлен признак «фиксированная государственная цена». [Новая цена] = [Базовая цена] * (1 + [Процент наценки для артикула]/100) Если параметр «Наценка от полной цены» («Склады и магазины», страница «Цены», таблица видов цен места хранения) не установлен, к получившейся новой цене прибавляются налоги, прикрепленные к артикулу на текущую дату для региона места прихода. При этом новая цена без НДС сравнивается с максимально разрешенной ценой без НДС, и если новая цена больше, ее значение устанавливается равной максимально разрешенной цене без НДС. Если нацениваемый вид цены не в базовой валюте, новая цена и максимально разрешенная цена полная преобразуются в валюту вида цены по курсу из исходного документа. Если в исходном документе курс не установлен, будет взят банковский курс на дату исходного документа. Новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>]. Если получившаяся величина больше максимально разрешенной цены полной, новая цена устанавливается равной максимально разрешенной цене полной


  1. Расчет новой цены для артикулов, добавленных на шаге 4 и для которых новая цена не была установлена на шагах 6 или 7. Новая цена = сумме долей цен компонентов комплексного артикула. Доля цены каждого компонента рассчитывается в зависимости от значения параметра «Метод наценивания наборов»: а) если параметр «Метод наценивания наборов» установлен в значение «От продажной цены»:[Доля цены компонента] = [Цена компонента] * [Кол-во] * [Процент от продажной цены] / 100 б) если параметр «Метод наценивания наборов» установлен в значение «От цены прихода»:[Доля цены компонента] = [Цена компонента] * [Кол-во] * (100 + [Наценка на цену прихода]) / (100 + [Процент наценки для артикула]) [Цена компонента] – это новая цена компонента, если он входит в перечень для наценивания, иначе это его текущая цена. [Кол-во], [Процент от продажной цены], [Наценка на цену прихода] - см. раздел «Карточки складского учета», страница «Состав». Новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>].


  1. В акт переоценки помещаются артикулы из перечня артикулов для наценивания, за исключением:


а) артикулов, для которых текущий вид цены планируется (т.е. существует план цен в статусе «Принят к исполнению» или «Исполнен» с планируемой датой установления цены <= текущей даты)
б) добавленных на шаге 4 комплексных артикулов, содержащих компоненты, которые не включены в перечень артикулов для наценивания или которые исключены на шаге 8а и текущая цена которых не установлена или = 0
в) артикулов, новая цена которых = текущей цене, если установлен параметр «Исключать не изменившиеся цены в наценивании по приходу» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»).

  1. В исходный документ в поле «Розничная цена» проставляется значение новой цены, если нацениваемый вид цены является ценой для кассы и если перед нацениванием это поле не было заполнено.


  1. Если среди видов цен, для которых был создан акт переоценки, есть цена для кассы, то такой акт становится источником синхронизации цен для кассы. Иначе источником станет первый попавшийся созданный акт для вида цены для кассы какого-либо оприходованного места хранения. На основании акта-источника будут созданы акты для всех оприходованных мест хранения (кроме места хранения накладной) и их видов цен для кассы. В новые акты будут помещены артикулы и цены из акта-источника, если цена из акта-источника меньше текущей цены в месте хранения нового акта и для артикула и вида цены нового акта установлена «Макс. наценка от цены произв.».



Алгоритм наценивания по накладной на перемещение (Беларусь)

(последнее изменение: 1.036.1)


  1. Акты переоценки создаются для каждого вида цены, назначенного месту хранения «Приход В».


  1. В перечень нацениваемых артикулов добавляются артикулы из исходного документа, если не установлен параметр «Наценивание по свойствам для артикула» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»). Если этот параметр установлен и если в спецификации исходного документа имеются ссылки на активные комплексные артикулы с ненулевым количеством и указанным свойством (поле «Свойство»), то в перечень для наценивания будут включены эти артикулы (см. поле «Арт. ценника»), а не их базовые артикулы из спецификации исходного документа. Прочие артикулы будут включены в перечень обычным образом.


  1. Определение базовой цены для артикулов, для которых в спецификации исходного документа не установлен признак «государственная фиксированная цена». Базовая цена рассчитывается в зависимости от значения параметра «Наценивание от цены производителя»: а) если параметр «Наценивание от цены производителя» не установлен:

[Базовая цена] = [Цена производителя] * (1 + [Надбавка оптовая / импортёра]/100)
б) если параметр «Наценивание от цены производителя» установлен: [Базовая цена] = [Цена производителя]
Если в исходном документе несколько строк с одним артикулом, то базовая цена рассчитывается согласно значению параметра «Цена повтор. артикула при наценивании» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»).

  1. Определение базовой цены для артикулов, для которых в спецификации исходного документа установлен признак «фиксированная государственная цена». В качестве базовой цены берется цена производителя из спецификации исходного документа. Предполагается, что в спецификации для каждого артикула будет только одна строка, иначе в качестве цены производителя будет взята максимальная цена производителя для данного артикула.


  1. В перечень нацениваемых артикулов добавляются активные комплексные артикулы, созданные на базе артикулов из спецификации исходного документа (если они не были добавлены в перечень для наценивания на шаге 1). При этом:


  • артикулы типа «размер» добавляются только при отключенном параметре «Наценивание по свойствам для артикула»;
  • артикулы типа «уценка» добавляются только при включенном параметре «Наценивать уценочные артикулы».
    Базовая цена для добавленных на этом шаге артикулов не определяется, т.к. их наценивание будет происходить на основе базовых цен их компонентов.
  1. Расчет новой цены для артикулов с положительной розничной ценой из спецификации исходного документа, если вид цены акта переоценки является ценой для кассы места хранения акта. Новая цена устанавливается = розничной цене из исходного документа.


  1. Расчет новой цены для артикулов с флагом «Фиксированная цена», для которых новая цена не была установлена на шаге 6. Новая цена устанавливается = текущей цене.


  1. Расчет новой цены для артикулов, добавленных на шаге 1, для которых новая цена не была установлена на шагах 6 или 7 и для которых в спецификации накладной установлен признак «фиксированная государственная цена». [Новая цена] = [Базовая цена] К получившейся новой цене прибавляются налоги, следующие в порядке применения после НДС и прикрепленные к артикулу на текущую дату для региона места прихода. Если нацениваемый вид цены не в базовой валюте, новая цена преобразуется в валюту вида цены по курсу из исходного документа. Если в исходном документе курс не установлен, будет взят банковский курс на дату исходного документа. Если новая цена получилась отличной от базовой цены, новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>].


  1. Расчет новой цены для артикулов, добавленных на шаге 1, для которых новая цена не была установлена на шагах 6 или 7 и для которых в спецификации накладной не установлен признак «фиксированная государственная цена». [Новая цена] = [Базовая цена] * (1 + [Процент наценки для артикула]/100) Если параметр «Наценка от полной цены» («Склады и магазины», страница «Цены», таблица видов цен места хранения) не установлен, к получившейся новой цене прибавляются налоги, прикрепленные к артикулу на текущую дату для региона места прихода. Если нацениваемый вид цены не в базовой валюте, новая цена преобразуется в валюту вида цены по курсу из исходного документа. Если в исходном документе курс не установлен, будет взят банковский курс на дату исходного документа. Новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>].


  1. Расчет новой цены для артикулов, добавленных на шаге 4 и для которых новая цена не была установлена на шагах 6 или 7. Новая цена = сумме долей цен компонентов комплексного артикула. Доля цены каждого компонента рассчитывается в зависимости от значения параметра «Метод наценивания наборов»: а) если параметр «Метод наценивания наборов» установлен в значение «От продажной цены»:[Доля цены компонента] = [Цена компонента] * [Кол-во] * [Процент от продажной цены] / 100 б) если параметр «Метод наценивания наборов» установлен в значение «От цены прихода»:[Доля цены компонента] = [Цена компонента] * [Кол-во] * (100 + [Наценка на цену прихода]) / (100 + [Процент наценки для артикула]) [Цена компонента] – это новая цена компонента, если он входит в перечень для наценивания, иначе это его текущая цена. [Кол-во], [Процент от продажной цены], [Наценка на цену прихода] - см. раздел «Карточки складского учета», страница «Состав». Новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>].


  1. В акт переоценки помещаются артикулы из перечня артикулов для наценивания, за исключением:


а) артикулов, для которых текущий вид цены планируется (т.е. существует план цен в статусе «Принят к исполнению» или «Исполнен» с планируемой датой установления цены <= текущей даты)
б) добавленных на шаге 4 комплексных артикулов, содержащих компоненты, которые не включены в перечень артикулов для наценивания или которые исключены на шаге 8а и текущая цена которых не установлена или = 0
в) артикулов с локальным ценообразованием (раздел «Карточки складского учета», страница «Цены», поле «Локальная»)
г) артикулов, новая цена которых = текущей цене, если установлен параметр «Не отсылать не изм. цены при перемещении» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»).

  1. В исходный документ в поле «Розничная цена» проставляется значение новой цены, если нацениваемый вид цены является ценой для кассы места хранения «Приход В» и если перед нацениванием это поле не было заполнено.



Округление новой цены


1. Если задано правило округления цены и в нем найдена настройка с максимальным значением «Порог цены», меньшем новой цены, новая цена округляется в соответствии с найденной настройкой.
2. Новая цена округляется до точности валюты.
3. Если шаг цены для артикула больше модуля разности новой и текущей цены и если текущая цена отлична от 0 или не установлен параметр «Игнорировать порог при нулевой цене» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»), новая цена устанавливается = текущей цене.

Основные термины.


Наценка для артикула – раздел «Карточки складского учета», страница «Цены», поле «Наценка». Если значение поля не установлено, берется значение поля «Наценка на группу».
Шаг цены для артикула – раздел «Карточки складского учета», страница «Цены», поле «Шаг цены». Если значение поля не установлено, берется значение поля «Шаг цены для группы».
Текущая цена артикула – раздел «Карточки складского учета», страница «Цены», поле «Цена» (при условии, что флаг «Маркетинговая цена» не установлен). Если текущая цена – маркетинговая, то в качестве текущей будет взята цена, которая будет установлена актом переоценки завершения маркетинговой акции.
Правила округления – раздел «Цены», страница «Правила округления цены». Описание правил округления см. раздел «Справочники», справочник «Правила округления».

Алгоритм наценивания по приходной накладной (Россия)

(последнее изменение: 1.046 SP1)


  1. Акты переоценки создаются для каждого вида цены, назначенного месту хранения прихода.


  1. В перечень нацениваемых артикулов добавляются артикулы из исходного документа, если не установлен параметр «Наценивание по свойствам для артикула» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»). Если этот параметр установлен и если в спецификации исходного документа имеются ссылки на активные комплексные артикулы с ненулевым количеством и указанным свойством (поле «Свойство»), то в перечень для наценивания будут включены эти артикулы (см. поле «Арт. ценника»), а не их базовые артикулы из спецификации исходного документа. Прочие артикулы будут включены в перечень обычным образом.


  1. Определение базовой цены.


Если параметр «Наценка от полной цены» («Склады и магазины», страница «Цены», таблица видов цен места хранения) установлен, в качестве базовой цены берется полная цена из спецификации исходного документа. Иначе берется цена без налогов.
Если в исходном документе несколько строк с одним артикулом, то базовая цена рассчитывается согласно значению параметра «Цена повтор. артикула при наценивании» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»). Если параметр «Наценивание по свойствам для артикула» не установлен и если в спецификации исходного документа есть артикулы с распределением ненулевого количества поставки по свойствам (поле «Свойство»), то базовая цена таких артикулов подвергается коррекции в соответствии со значением «Процент цены поставки» (см. раздел «Свойства для артикулов», страница «Цены поставки»). Т.к. поставщик приходной накладной может поставлять разные значения свойства одного артикула с разными ценами, то базовую цену нужно скорректировать, чтобы при приходе разных значений свойства не менялась цена базового артикула:[Базовая цена] = [Базовая цена] * 100 / [Процент цены поставки]Данная функциональность работает корректно при наличии в приходной накладной только одного значения свойства артикула. Иначе в качестве процента цены поставки будет взято максимальное значение процента цены поставки из всех значений встречающихся в приходе свойств.

  1. В перечень нацениваемых артикулов добавляются активные комплексные артикулы, созданные на базе артикулов из спецификации исходного документа (если они не были добавлены в перечень для наценивания на шаге 2).


При этом:

  • артикулы типа «размер» добавляются только при отключенном параметре «Наценивание по свойствам для артикула»;
  • артикулы типа «уценка» добавляются только при включенном параметре «Наценивать уценочные артикулы».
    Базовая цена для добавленных на этом шаге артикулов не определяется, т.к. их наценивание будет происходить на основе базовых цен их компонентов.
  1. Расчет новой цены для артикулов с флагом «Фиксированная цена». Новая цена устанавливается = текущей цене.


  1. Расчет новой цены для артикулов без признака «Фиксированная цена», добавленных на шаге 2. 6.1. [Новая цена] = [Базовая цена] * (1 + [Процент наценки для артикула]/100) Если параметр «Наценка от полной цены» («Склады и магазины», страница «Цены», таблица видов цен места хранения) не установлен, к получившейся новой цене прибавляются налоги, прикрепленные к артикулу на текущую дату для региона места прихода. Если нацениваемый вид цены не в базовой валюте, новая цена преобразуется в валюту вида цены по курсу из исходного документа. Если в исходном документе курс не установлен, будет взят банковский курс на дату исходного документа. Новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>].


    1. Дополнительный расчет для случая, когда нацениваемый вид цены выбран для места хранения как «вид цены для кассы».


Если артикул не является комплексным и входит в группу классификатора товаров, для которой установлен признак «Наценивание прямых приходов «Средневзвешенная розничная цена»», то
[Новая цена] = ( [Новая цена] * [Кол-во прихода] + [Текущая цена для кассы] * [Остаток] ) / ( [Кол-во прихода] + [Остаток] ),
где [Остаток] = [Оперативные остатки] – [Потери] (отрицательное значение обнуляется),
[Оперативные остатки], [Потери] - см. раздел «Карточки складского учета», страница «Остатки».
Новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>].

  1. Расчет новой цены для артикулов без признака «Фиксированная цена», добавленных на шаге 4. Новая цена = сумме долей цен компонентов комплексного артикула. Доля цены каждого компонента рассчитывается в зависимости от значения параметра «Метод наценивания наборов» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»): а) если параметр «Метод наценивания наборов» установлен в значение «От продажной цены»:[Доля цены компонента] = [Цена компонента] * [Кол-во] * [Процент от продажной цены] / 100 б) если параметр «Метод наценивания наборов» установлен в значение «От цены прихода»:[Доля цены компонента] = [Цена компонента] * [Кол-во] * (100 + [Наценка на цену прихода]) / (100 + [Процент наценки для артикула]) [Цена компонента] – это новая цена компонента, если он входит в перечень для наценивания, иначе это его текущая цена. [Кол-во], [Процент от продажной цены], [Наценка на цену прихода] - см. раздел «Карточки складского учета», страница «Состав». Новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>].


  1. В акт переоценки помещаются артикулы из перечня артикулов для наценивания, за исключением:


а) артикулов, для которых текущий вид цены планируется (т.е. существует план цен в статусе «Принят к исполнению» или «Исполнен» с планируемой датой установления цены <= текущей даты)
б) добавленных на шаге 3 комплексных артикулов, содержащих компоненты, которые не включены в перечень артикулов для наценивания или которые исключены на шаге 8а и текущая цена которых не установлена или = 0
в) артикулов, новая цена которых = текущей цене, если установлен параметр «Исключать не изменившиеся цены в наценивании по приходу» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»).

Алгоритм наценивания по контракту с поставщиком (Россия)

(последнее изменение: 1.036)


  1. Акты переоценки создаются для каждого места хранения из оприходованных соглашений о поставках, созданных на основании рассматриваемого контракта с поставщиком, и для каждого назначенного месту хранения вида цены.


  1. В перечень нацениваемых артикулов добавляются артикулы с ненулевой базовой ценой из исходного документа, если они также входят в созданное на основании рассматриваемого контракта оприходованное соглашение о поставках в текущее рассматриваемое место хранения. Под базовой ценой понимается полная цена из контракта с поставщиком, если параметр «Наценка от полной цены» («Склады и магазины», страница «Цены», таблица видов цен места хранения) установлен. Иначе берется цена без налогов.


  1. В перечень нацениваемых артикулов добавляются активные комплексные артикулы, созданные на базе артикулов, добавленных в перечень для наценивания на шаге 2. При этом артикулы типа «уценка» добавляются только при включенном параметре «Наценивать уценочные артикулы». Базовая цена для добавленных на этом шаге артикулов не определяется, т.к. их наценивание будет происходить на основе базовых цен их компонентов.


  1. Расчет новой цены для артикулов с флагом «Фиксированная цена». Новая цена устанавливается = текущей цене.


  1. Расчет новой цены для артикулов без признака «Фиксированная цена», добавленных на шаге 2. [Новая цена] = [Базовая цена] * (1 + [Процент наценки для артикула]/100). Если параметр «Наценка от полной цены» («Склады и магазины», страница «Цены», таблица видов цен места хранения) не установлен, к получившейся новой цене прибавляются налоги, прикрепленные к артикулу на текущую дату для региона текущего рассматриваемого места хранения. Если нацениваемый вид цены не в базовой валюте, новая цена преобразуется в валюту вида цены по курсу из исходного документа. Если в исходном документе курс не установлен, будет взят банковский курс на дату исходного документа. Новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>].


  1. Расчет новой цены для артикулов без признака «Фиксированная цена», добавленных на шаге 3. Новая цена = сумме долей цен компонентов комплексного артикула. Доля цены каждого компонента рассчитывается в зависимости от значения параметра «Метод наценивания наборов» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»): а) если параметр «Метод наценивания наборов» установлен в значение «От продажной цены»:[Доля цены компонента] = [Цена компонента] * [Кол-во] * [Процент от продажной цены] / 100 б) если параметр «Метод наценивания наборов» установлен в значение «От цены прихода»:[Доля цены компонента] = [Цена компонента] * [Кол-во] * (100 + [Наценка на цену прихода]) / (100 + [Процент наценки для артикула]) [Цена компонента] – это новая цена компонента, если он входит в перечень для наценивания, иначе это его текущая цена. [Кол-во], [Процент от продажной цены], [Наценка на цену прихода] - см. раздел «Карточки складского учета», страница «Состав». Новая цена [<span style="color: #0000ff"><span style="text-decoration: underline; ">округляется</span></span>].


  1. В акт переоценки помещаются артикулы из перечня артикулов для наценивания, за исключением:


а) артикулов, для которых текущий вид цены планируется (т.е. существует план цен в статусе «Принят к исполнению» или «Исполнен» с планируемой датой установления цены <= текущей даты)
б) добавленных на шаге 3 комплексных артикулов, содержащих компоненты, которые не включены в перечень артикулов для наценивания или которые исключены на шаге 7а и текущая цена которых не установлена или = 0
в) артикулов, новая цена которых = текущей цене, если установлен параметр «Исключать не изменившиеся цены в наценивании по контракту» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»).

Округление новой цены


1. Правило округления ищется для группы классификатора артикула. Если оно не задано, ищется правило округления для вида цены. Если правило округления обнаружено и в нем найдена настройка с максимальным значением «Порог цены», меньшем новой цены, новая цена округляется в соответствии с найденной настройкой.
2. Новая цена округляется до точности валюты.
3. Если шаг цены для артикула больше модуля разности новой и текущей цены: если текущая цена отлична от 0 или не установлен параметр «Игнорировать порог при нулевой цене» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»), новая цена устанавливается = текущей цене.

Алгоритм наценивания по накладной на перемещение (Россия)

(последнее изменение: 1.032)


  1. Акты переоценки создаются для каждого вида цены, назначенного одновременно месту хранения «В» и месту хранения «ИЗ». Если перемещение на склад возврата, для которого выставлен флаг «Акты смены цены на складе возврата копируют цены в учетные» (раздел «Склады и магазины», страница «Цены»), то акты переоценки будут также созданы для учетного вида цены места хранения «В», даже если этот вид цены не назначен месту хранения «ИЗ».
  2. Наценивание происходит для прямых перемещений с центрального или локального склада, для прямых перемещений со склада магазина в торговый зал магазина и для перемещений на склад возврата. При этом место хранения «В» должно иметь метод ценообразования «Переоценка при перемещении» (раздел «Склады и магазины», страница «Цены»).
  3. В перечень нацениваемых артикулов добавляются артикулы из исходного документа, если не установлен параметр «Наценивание по свойствам для артикула». Если этот параметр установлен и если в спецификации исходного документа имеются ссылки на активные комплексные артикулы с ненулевым количеством и указанным свойством (поле «Свойство»), то в перечень для наценивания будут включены эти артикулы (см. поле «Арт. ценника»), а не их базовые артикулы из спецификации исходного документа. Прочие артикулы будут включены в перечень обычным образом.

Для перемещений с локального склада перечень нацениваемых артикулов ограничивается только теми артикулами из спецификации исходного документа, которые входят в действующее обязательство текущего локального склада (тип документа «Обязательство склада»), среди мест поставки которого есть место хранения «В» текущей накладной.

  1. В перечень нацениваемых артикулов добавляются активные комплексные артикулы, созданные на базе артикулов из спецификации исходного документа (если они не были добавлены в перечень для наценивания на шаге 3). При этом артикулы типа «размер» добавляются только при отключенном параметре «Наценивание по свойствам для артикула».
  2. Старая цена = текущая цена текущего вида цены места хранения «В».
  3. Новая цена = текущая цена текущего вида цены места хранения «ИЗ». Если перемещение на склад возврата, для которого выставлен флаг «Акты смены цены на складе возврата копируют цены в учетные» (раздел «Склады и магазины», страница «Цены»), то новая цена = текущее значение учетного вида цены места хранения «ИЗ».
  4. В акт переоценки помещаются артикулы из перечня артикулов для наценивания, за исключением:


а) артикулов, для которых текущий вид цены планируется (т.е. существует план цен в статусе «Принят к исполнению» или «Исполнен» с планируемой датой установления цены <= текущей даты)
б) добавленных на шаге 4 комплексных артикулов, содержащих компоненты, которые не включены в перечень артикулов для наценивания или которые исключены на шаге 7а и текущая цена которых не установлена или = 0 в) артикулов с локальным ценообразованием (раздел «Карточки складского учета», страница «Цены», поле «Локальная»)
г) артикулов, новая цена которых = старой цене, если установлен параметр «Не отсылать не изм. цены при перемещении» (Административный модуль, страница «База данных – Конфигурация - Ценообразование»).


Алгоритм расчета количества предложения заказа ЕТС

(на базе процесса ORET).


Основные термины.


Процесс – процесс типа «ORET», на основании данных которого происходит расчет количества предложения заказа для артикулов из спецификации этого процесса.
Контракт – контракт с поставщиком, номер которого сохранен в заголовке процесса.
Поставщик – поставщик из заголовка процесса.
Распределительный центр (РЦ) - место хранения, для которого формируется заказ.
Дата ближайшего заказа = дата старта процесса.
Дата ближайшей поставки = [Дата ближайшего заказа] + [Срок поставки из контракта]. Если [Дата ближайшей поставки] не разрешена для поставки, [Дата ближайшей поставки] = ближайшей дате дня недели после [Дата ближайшей поставки], разрешенного для поставки.
Дата ближайшей готовности к продаже = [Дата ближайшей поставки] + наименьшее целое, большее или равное ( [Время обработки на складе из контракта] / 24 ).
Дата следующего заказа = [Дата ближайшего заказа] + [Частота заказа из контракта или 1, если частота заказа из контракта = 0]. Если [Дата следующего заказа] не разрешена для заказа, [Дата следующего заказа] = ближайшей дате дня недели после [Дата следующего заказа], разрешенного для заказа. Дата следующего заказа рассматривается, даже если она выходит за рамки действия контракта.
Дата следующей поставки = [Дата следующего заказа] + [Срок поставки из контракта]. Если [Дата следующей поставки] не разрешена для поставки, [Дата следующей поставки] = ближайшей дате дня недели после [Дата следующей поставки], разрешенного для поставки.
Дата следующей готовности к продаже = [Дата следующей поставки] + наименьшее целое, большее или равное ( [Время обработки на складе из контракта] / 24 ).
Дневной расход дня недели – среднесуточная реализация (ССР) по дням недели, сохраненная в спецификации процесса до начала расчета количества предложения заказа. Расчет ССР ведется по накладным и кассовым документам с операцией «Продажа», исключая дни, для которых [остаток на конец дня + продажи] <= 0, за период N*7 дней, предшествующих дате ближайшего заказа (не включая дату ближайшего заказа). N – период усреднения, назначаемый группам классификатора товаров в интерфейсе процесса.
Средний дневной расход = ( [Дневной расход понедельника] + … + [Дневной расход воскресенья] ) / 7.
Сумма дневных расходов за период = [Дневной расход понедельника][Кол-во понедельников за период] + … + [Дневной расход воскресенья][Кол-во воскресений за период].
Минимальный уровень складских запасов, Минимум в днях, Коэффициент вариативности - раздел «Карточки складского учета», вкладка «Заказ», поля, соответственно, «Зал», «Мин. дней», «Коэффициент вариативности».
Коэффициент срока поставки – раздел «Контрагенты», вкладка «Поставщик», поле «Коэффициент срока поставки».

Общая схема.

Формирование количества заказа для текущего артикула для РЦ и сохранение результата в спецификации процесса.
Список распределительных центров (РЦ) – из заголовка процесса
Для текущего РЦ: список артикулов – из спецификации процесса и контракта







Алгоритм расчета количества предложения заказа.


да
нет
[Остаток на день ближайшей поставки]
= [Текущие остатки РЦ. Поставка]
[Срок реализации] текущего артикула не установлен или больше 1.
[Остаток на день ближайшей поставки]
= [Текущие остатки РЦ. Поставка]
+ ( ([Текущие остатки РЦ. Текущий остаток] - [Текущие остатки РЦ. Потери]) (отрицательное значение обнуляется) )
да
нет
[Средний дневной расход] = 0 и
[Остаток на день ближайшей поставки] >= [Минимальный уровень РЦ]
Заказ для текущего артикула сформирован не будет.
Поиск количества заказа.08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100300030003400350038003300340030000000



































































Поиск количества заказа.


да
нет
[Средний дневной расход] = 0
[Кол-во заказа] = [Минимальный уровень РЦ] – [Остаток на день ближайшей поставки]
да
нет
[Срок реализации] текущего артикула не установлен или больше 1.
[Кол-во заказа]
= [Дневной расход дня недели, на который приходится дата ближайшей готовности к продаже]
[Остаток на день ближайшей поставки] = 0
[Остаток на день ближайшей поставки]
= [Остаток на день ближайшей поставки]

  • ( Сумма дневных расходов за период с [Текущая дата] по [Дата ближайшей готовности к продаже] ). Если получилась отрицательная величина, она обнуляется.
    [Интервал между поставками]
    = [Дата следующей готовности к продаже]

  • [Дата ближайшей готовности к продаже]
    да
    нет
    [Срок реализации] установлен и меньше [Интервал между поставками]
    [Интервал между поставками] = [Срок реализации]
    [Кол-во заказа] = [Мин. уровень РЦ]
    + { ( Сумма дневных расходов за период [Интервал между поставками], начиная с [Дата ближайшей готовности к продаже] ) - [Остаток на день ближайшей поставки]
    } * [Коэф. вариативности] * ( 1 + [K1] + [Коэф. срока поставки] )
    да
    нет
    [Размер упаковки] из контракта > 0
    [Кол-во заказа] = [Размер упаковки] * округленное по математическим правилам отношение ( [Кол-во заказа] / [Размер упаковки] )
    да
    нет
    [Кол-во заказа] = 0 и
    [Остаток на день ближайшей поставки] <= 0
    [Кол-во заказа] = [Размер упаковки]
    [Кол-во заказа]да
    нет
    [Остаток на день ближайшей поставки] > 0
    [K1] = [Минимум в днях] / ( [Дата следующей готовности к продаже] - [Текущая дата] )
    [K1] = [Минимум в днях] / [Интервал между поставками]




































































Алгоритм расчета себестоимости (с/с) в производстве.


Расчет с/с в производстве всегда ведется по методу FIFO, вне зависимости от настроек партнера или системных настроек. Расчет требует наличия рассчитанной с/с (FIFO или средневзвешенной) на складе, т.к. с/с документов расхода на производство определяется с/с этих документов на складе.
Под приходами в производство и расходами из производства понимаются документы, увеличивающие или уменьшающие количество товара в цеху.

Общая схема.

Для текущего артикула и цеха:

  1. Расчет себестоимости приходов.
  2. Расчет себестоимости расходов.

Список цехов
Для текущего цеха:
Список групп артикулов.
Для текущей группы артикулов и цеха:
Список артикулов.









Список групп артикулов.


Расчет с/с ведется автономно для каждого артикула внутри каждого цеха. Однако с/с артикула, произведенного в производстве, зависит от с/с его ингредиентов. Поэтому, перед расчетом все артикулы внутри цеха группируются таким образом, чтобы в каждую следующую группу попадали артикулы, зависящие только от артикулов предыдущих групп. Расчет будет переходить к артикулам каждой следующей группы только после обработки всех артикулов предыдущей группы.
Порядок групп следующий:
1 группа. Артикулы, входящие в производство только через расходы на производство.
2 группа. Артикулы, не имевшие приходов в производство, но расходуемые из него через возвраты из производства, выходы из производства или акты производства. Это артикулы, с/с расходов которых будет неопределенной и нулевой.
3 группа – N группа. Артикулы, поступавшие в производство через акты производства. В каждую N-ую группу будут включены артикулы, исходным сырьем для производства которых послужили артикулы, включенные в группы с 1 по N-1.
N+1 группа. Артикулы, имевшие приходы в производство, но по каким-либо причинам не вошедшие в предыдущие группы.
N+2 группа. Артикулы, имевшие расходы из производства, но по каким-либо причинам не вошедшие в предыдущие группы.
Группы N+1 и N+2 могут оказаться заполненными, если производство, с точки зрения торговой системы, ведется некорректно. Например, были акты производства, в одном из которых [артикул 1] служил сырьем для [артикула 2], а в другом [артикул 2] служил сырьем для [артикула 1].

Расчет себестоимости приходов для артикула и цеха.


Расход на производство: с/с совпадает с с/с данного документа, посчитанной при расчете с/с на складе.
Акт производства типа «сборка»: с/с равна сумме с/с исходного сырья, т.е. артикулов, расходуемых на производство текущего артикула.
Акт производства типа «разделка»: с/с равна произведению с/с разделываемого артикула и коэффициента цены.

Расчет себестоимости расходов для артикула и цеха.


Для расчета с/с расходов по методу FIFO составляются два списка документов:

  • список расходов - список расходных документов с сортировкой по дате. Внутри одной даты вначале обрабатываются акты производства, потом выходы из производства, потом возвраты из производства. Внутри одного типа документов документы сортируются по номеру.

  • список приходов - список приходных документов с сортировкой по дате. Внутри одной даты вначале обрабатываются расходы на производство, потом акты производства. Внутри одного типа документов документы сортируются по номеру.
    Первый расход из списка расходов.
    [Нераспределенное кол-во расхода] = [Кол-во документа расхода]
    [С/с расхода] = 0Список приходов пуст
    нет
    да
    Если в исходном списке приходов найдется последний приход с датой <= дате расхода, то
    [С/с расхода] = [С/с расхода]
    + [С/с прихода]

  • [Нераспределенное кол-во расхода] / [Кол-во документа прихода]
    Первый приход из списка приходов.
    [Свободное кол-во прихода]
    = [Кол-во документа прихода]
    [С/с прихода] см. [Расчет себестоимости приходов для артикула и цеха.]
    во расхода] = [Кол-во документа расхода]
    [С/с расхода] = 0[Нераспределенное кол-во расхода] <= 0
    нет
    да
    Переход к следующему расходу.
    [Нераспределенное кол-во расхода]
    = [Кол-во документа расхода]
    [С/с расхода] = 0
    Есть следующий расход
    нет
    да
    С/с всех расходов определена
    [Дата прихода] > [Дата расхода]
    нет
    да
    [Распределяемое кол-во]
    = min ( [Свободное кол-во прихода], [Нераспределенное кол-во расхода] )
    [С/с расхода] = [С/с расхода] + [С/с прихода] * [Распределяемое кол-во] / [Кол-во документа прихода]
    [Нераспределенное кол-во расхода]
    = [Нераспределенное кол-во расхода] - [Распределяемое кол-во]
    [Свободное кол-во прихода]
    = [Свободное кол-во прихода] - [Распределяемое кол-во]
    [Свободное кол-во прихода] > 0
    нет
    да
    Удаляем текущий приход из списка приходов


























































Примечание по поводу неопределенной с/с.



Если часть расхода не удалось нормально привязать к приходу, дата которого <= дате расхода, то эта часть будет привязана форсированно (по неопределенной с/с) к последнему приходу, дата которого <= дате расхода.
Если часть расхода удалось нормально привязать к приходу, дата которого <= дате расхода, то с/с этой части расхода будет считаться полностью определенной, вне зависимости от степени определенности с/с прихода, к которому произошла привязка.
С/с приходов в производство через акт производства всегда определенная.



Алгоритм расчёта среднесуточной реализации (ССР)

для одного места хранения (МХ) и одного артикула.


Алгоритм расчета ССР предназначен для определения среднего объема реализации товара, как прогноза будущей реализации. Он использует данные о приходе и расходе товара из базы данных, а также информацию о праздничных днях, маркетинговых акциях и других факторов, которые могут повлиять на продажи и внести искажение в прогнозируемый спрос. Результаты расчета могут быть использованы для прогнозирования будущих продаж и принятия решений о ценах, запасах и маркетинге.
Основой алгоритма является определение дней, которые считаются пригодными для расчета ССР. В основе лежит выбранный диапазон дней с известной реализацией, например, месяц, и исключение из этого перечня дней, которые могут внести искажение в прогноз. Например, дни, когда товара в магазине нет, снижают общий прогноз, несмотря на то, что спрос на товар из-за этого не исчезает.

Основные термины.


Дни расчёта – дни, которые входят в диапазон расчёта, задаваемый в параметрах расчёта, и отвечают условиям опции расчёта «Учёт дней».
Приход в МХ – оприходованный документ прихода в МХ. Типы и системные операции документов, участвующих в расчёте, описываются в опции расчёта «Операции». В расчёте участвуют документы с датами, входящими в перечень дней расчёта (но не больше текущей даты).
Расход из МХ – оприходованный документ расхода из МХ. Типы и системные операции документов, участвующих в расчёте, описываются в опции расчёта «Операции». В расчёте участвуют документы с датами, входящими в перечень дней расчёта (но не больше текущей даты).
«Реализация» – суммарное количество расходов товара из МХ из документов «Расход из МХ» за вычетом количества приходов в МХ из документов «Приход в МХ» (например, продажи минус возвраты от покупателя). Термин взят в кавычки, т.к. хотя изначально алгоритм предназначался именно для расчёта среднесуточной реализации, сейчас, благодаря опции расчёта «Операции», его можно использовать для расчёта любого среднесуточного движения, например, для расчёта среднесуточного перемещения.
«Продажи» – расходы из МХ (не обязательно собственно продажи покупателю). Данный термин используется при задании параметров расчёта «Учёт дней – Из расчёта исключать дни по условию».
Остаток – остаток товара в МХ, образованный всеми документами товародвижения в статусах «принят на складе» («розовая галка») и «оприходован» («зеленая галка»). Расчёт остатка ведется по всем документам, влияющим на остаток, и не зависит от параметров расчёта ССР. Данный термин используется при задании параметров расчёта «Учёт дней – Из расчёта исключать дни по условию».
Выходной день – это стандартный выходной день (суббота, воскресенье, праздничный день) или дополнительный выходной день, исключая дополнительный рабочий день. Перечень праздничных дней, дополнительных рабочих и дополнительных выходных дней задается в справочнике «Календарь». Данный термин используется при задании параметров расчёта «Учёт дней – Учёт в расчёте выходных дней».
Особый день – это день, отличающийся от прочих дней по какому-либо признаку (например, дни, в которые прогнозируются резкое увеличение или спад продаж). Перечень категорий особых дней задается в справочнике «Категории особых дней». Перечень особых дней задается в справочнике «Календарь». Данный термин используется при задании параметров расчёта «Учёт дней – Учёт в расчёте категорий особых дней».
Автоматический расчёт ССР – расчёт, запускаемый без непосредственного участия пользователя, по расписанию. См. «Административный модуль – Аналитика – Среднесут. реал-ция». В этом расчёте участвуют только активные артикулы, без установленного флага «Запретить автоматический расчёт» и только относящиеся к тем группам, которые указаны в задании.
Опции для автоматического расчёта ССР задаются для каждого артикула отдельно в разделе «Карточки складского учёта» на странице «Среднесут. реал-ция». Если для артикула выставлен флаг «Параметры по умолчанию (из группы классификатора)», то опции для расчёта данного артикула будут взяты из группы классификатора, в которую входит этот артикул. Параметры расчёта для группы классификатора задаются в разделе «Классификатор товаров» на странице «Среднесут. реал-ция». Если для группы классификатора выставлен флаг «Параметры по умолчанию (из старшей группы классификатора)», то опции для расчёта всех артикулов, входящих в данную группу и не имеющих собственных параметров расчёта, будут браться из старшей по отношению к текущей группе группы классификатора.
Опции автоматического расчёта могут быть определены индивидуально, для конкретного задания на автоматический расчёт ССР. Для этого необходимо снять флаг «Параметры по умолчанию» и переопределить параметры расчёта. Тогда, для всех артикулов, описанных в задании, расчёт будет вестись с использованием параметров задания, не зависимо от опций расчёта, установленных для артикулов или их групп классификатора.
Акция (документ изменения спроса) – документ «Прогноз изменения спроса» в статусе «Принят» или документ «Маркетинговая акция» в статусе «Исполняется» или «Завершена».
Дата начала акции – дата начала изменения спроса из документа «Прогноз изменения спроса» или планируемая дата начала акции (без учёта времени) из документа «Маркетинговая акция».
Дата окончания акции – дата окончания изменения спроса из документа «Прогноз изменения спроса» или фактическая дата окончания акции (без учёта времени) из документа «Маркетинговая акция». Если для маркетинговой акции фактическая дата окончания не установлена, то берётся планируемая дата окончания акции (без учёта времени).


Опции (параметры) расчёта ССР.


Операции – перечень пар «тип документа – системная операция». В расчёте будут участвовать только оприходованные документы, соответствующие указанному перечню типов документов и операций.
Диапазон расчёта – определяет временной промежуток, за который будет анализироваться «реализация». Если будет выбрана опция «за все время продаж», то для артикула диапазон расчёта будет ограничен наименьшей и наибольшей (но не больше текущего дня) датами документов прихода данного артикула в МХ или расхода из МХ, имеющихся в системе (документы будут учитываться только с соответствующими операциями, заданными в опции «Операции»).
Исключать из расчёта движение по артикулам типа «уценка» – системный параметр. Если этот параметр установлен, в расчёте не будут участвовать позиции спецификации документов, у которых в поле «Артикул ценника» указан артикул типа «уценка».
Значение данного параметра игнорируется в разделе «Среднесуточная реализация».
Влияние документов изменения спроса – системный параметр. Если этот параметр установлен, то на расчёт ССР влияют акции, период действия которых пересекается с диапазоном расчёта. Значение данного параметра игнорируется в разделе «Среднесуточная реализация».
Если параметр установлен в значение «Уменьшать диапазон расчёта при наличии акций» или «Включать или исключать дни акций», и последний день диапазона расчёта попадает в период действия акции, то результатам расчёта присваивается признак «Среднесуточная реализация посчитана в период изменения спроса».
Возможны следующие варианты влияния акций на расчёт:
Влияние документов изменения спроса: Уменьшать диапазон расчёта при наличии акций.
Дата начала диапазона расчёта смещается в следующих случаях:

  • если у найденной акции дата окончания меньше последней даты диапазона расчёта, то дата начала диапазона расчёта становится равной дате окончания акции плюс один день;

  • если у найденной акции дата начала попадает в диапазон расчёта, а дата окончания больше или равна последней даты диапазона расчёта, то дата начала диапазона расчёта смещается и становится равной дате начала акции.
    Если акций, влияющих на смещение даты начала расчёта, найдено несколько, то для каждой считается новая дата начала диапазона расчёта и из полученных значений берётся наибольшее.
    Влияние документов изменения спроса: Включать или исключать дни акций.
    Если последняя дата диапазона расчёта попадает в период действия акции, то из периода расчёта будут исключены все дни, во время которых не было никаких акций. Если же в последнюю дату диапазона расчёта не было акций, то из периода расчёта будут исключены все дни акций.
    Влияние документов изменения спроса: С учётом коэффициентов изменения спроса.
    Количество реализации каждого дня перед расчётом корректируется с учётом коэффициентов спроса.
    Если в диапазоне расчёта начинается акция, то реализация за все дни, предшествующие дате начала акции, умножается на коэффициент спроса начала.
    Если в диапазоне расчёта завершается акция, то реализация за дату завершения акции и за все предшествующие дни умножается на коэффициент спроса конца и делится на коэффициент спроса начала.
    Все такие акции влияют совокупно, то есть коэффициенты, изменяющие реализацию, перемножаются.
    Например, реализация по данным базы данных за период 11 – 17 января:
    11 января 15 штук
    12 января 12 штук
    13 января 13 штук
    14 января 14 штук
    15 января 10 штук
    16 января 10 штук
    17 января 11 штук
    В это время были акции:
    12 января – 17 января – акция [K1] = 1.5, [K2] = 0.8;
    13 января – 25 января – акция [K1] = 1.1, [K2] = 0.9.
    Тогда реализация будет откорректирована следующим образом:
    11 января 15 * 1.5 * 1.1 * [0.8 / 1.5] = 13.2 штук
    12 января 12 * 1.1 * [0.8 / 1.5] = 7.04 штук
    13 января 13 * [0.8 / 1.5] = 6.933 штук
    14 января 14 * [0.8 / 1.5] = 7.467 штук
    15 января 10 * [0.8 / 1.5] = 5.333 штук
    16 января 10 * [0.8 / 1.5] = 5.333 штук
    17 января 11 * [0.8 / 1.5] = 5.867 штук

    Учёт дней – определяет перечень дней, входящих в диапазон расчёта, которые будут включены в расчёт или исключены из него. Если опция не установлена, то в расчёт будут включены все дни диапазона расчёта. Если опция установлена, то в расчёте будут учитываться только дни, отвечающие условиям этой опции. Условий в данной опции может быть задано несколько, поэтому день будет включен в расчёт, только если он отвечает всем условиям этой опции. Например, если указать условия «Из расчёта исключать дни недели: ПнВтСрЧтПт» и «Включать в расчёт только выходные дни», то в расчёт будут включены только те субботы и воскресенья, которые не объявлены в системе как дополнительные рабочие дни, а прочие выходные дни (например, праздники) в расчёт включены не будут, если только они не приходятся на субботу или воскресенье.
    Исключать выбросы – при установке опции из диапазона расчёта будут исключены дни, в которые «реализация» имеет необычно большое или маленькое значение. Это исключение происходит после того, как были исключены дни расчёта по всем другим критериям. Выбросы исключаются по фильтру Хампеля. После применения этого фильтра в расчёте останутся дни с «реализацией», входящей в диапазон от [MEDIAN] - 3 * [MAD] до [MEDIAN] + 3 * [MAD], где
    [MEDIAN] – медиана выборки значений «реализации» по всем дням, включенным в расчёт = median(Yi);
    [MAD] - медианное абсолютное отклонение, т.е. медиана абсолютных отклонений от медианы выборки = median(|Yi – [MEDIAN]|), где Yi - «реализация» за i-ый день расчёта.
    Метод расчёта – определяет вариант расчёта величины среднесуточной реализации.

    Метод расчёта «Среднее значение».


    ССР = «Реализация» / Количество дней расчёта. Отрицательное значение обнуляется.

    Метод расчёта «Медиана».


    За прогнозное значение ССР берётся медиана реализации среди всех значений диапазона расчёта. То есть определяются количества реализации по дням периода, сортируются в порядке возрастания, и то количество, которое соответствует середине этого упорядоченного массива, и будет медианой. Чтобы медиана давала хороший прогноз надо, чтобы в набор данных для расчёта попало бы не менее семи дней.
    Медиана – это значение, соответствующее середине упорядоченного по возрастанию числового ряда.
    ССР = median(«Реализация»). Отрицательное значение обнуляется.

    Метод расчёта «Линейная регрессия».


    Линейная регрессия позволяет определять прогноз реализации в будущем по результатам в прошлые дни, как функция, которая прогнозирует величину реализации для каждого следующего дня после последнего дня расчета. Результаты зависят не только от величин реализации в прошлом, но и от тенденций роста или падения продаж в прошлом периоде. Для определения среднего объема будущих реализаций берется только одна величина из множества чисел, которые дает линейная функция регрессии. Например, для еженедельных поставок хорошо брать прогноз на третий день от последнего дня расчета, а сам расчет проводить непосредственно перед использованием его результатов. Чтобы линейная регрессия давала хороший результат надо, чтобы в набор данных для расчета попало бы не менее десяти дней.
    Линейная регрессия – это функция, описывающая соответствие между случайными переменными. В данном случае используется парная (простая) линейная регрессия: y = a + b * x,
    где
    b - коэффициент наклона линии,
    a - точка пересечения линии с осью y,
    x - независимая переменная (порядковый номер дня в массиве включенных в расчёт дат),
    y - зависимая переменная («Реализация»).
    Анализу подвергается массив пар «Порядковый номер дня» - «Реализация», упорядоченный в порядке возрастания включенных в расчёт дат. Для полученного массива методом наименьших квадратов определяются коэффициенты a и b.
    Цельюрасчёта является прогнозирование ССР на N дней. N задается пользователем в клиентской части.
    ССР = a + b * ([количество дней в массиве] + [N / 2, округленное в большую сторону, не меньшее 1]). Отрицательное значение обнуляется.
    ССР дня недели = a + b * ([кол-во соответствующих дней недели в массиве] + [N / 7, округленное в большую сторону, не меньшее 1]). Отрицательное значение обнуляется.


    Изменения в функционале версии 1.017.1

    Изменения в почтовом модуле.


    В SMPostServer и SMSrvCtl добавлена поддержка нового интерфейса уведомлений, что позволило обновлять значки состояния баз данных в дереве MMC при остановке/старте базы.
    В SmSvcCtl добавлена возможность получения справки (help'а) по управлению почтовым модулем. Справка доступна только тогда, когда активен ActiveX управления почтовым модулем, т.е. когда в правой части консоли отображаются «закладки» или вызванные из них диалоги. Файл справочной системы должен называться SMPost.hlp и располагаться в том же каталоге, что и SmSvcCtl.dll.
    Обработка ошибок, возникающих в потоках приема и отправки почтового сервера, изменена таким образом, чтобы почтовый модуль не останавливался ни при каких ошибочных ситуациях, за исключением случая потери связи с базой данных Oracle.
    Выдача сообщений типа «внутренняя ошибка » при неверном формате пакета подтверждения заменена более детальной диагностикой.
    Добавлена возможность раздельного запуска процессов отправки и получения информации. Внесены изменения в описание старта почтового сервиса. Теперь можно указать, что какой-либо из этих двух процессов не будет активизироваться при автостарте базы. В интерфейсе сервиса состояние почтового сервера имеет пять отображений – пассивное состояние, при отсутствии соединения с базой данных; состояние готовности (желтые стрелки), при наличии соединения с базой данных; три состояния работы – запущен процесс приема (зеленая стрелка вниз), процесс отправления (зеленая стрелка вверх) или оба процесса.
    В интерфейсе управления пакетами добавлена поддержка выполнения операций уничтожения и отмены над выбранной группой виртуальных пакетов. Ранее эти операции могли обрабатывать только один пакет. Изменена схема генерации идентификатора виртуального пакета (реализована сохраненными процедурами), которая теперь исключает повторное использование идентификатора удаленного виртуального пакета для другого пакета.
    Примечание: При отправке информационных объектов их идентификаторы помещаются в очередь на отправку, далее в цикле отсылки данные объекты помещаются в виртуальные пакеты, из которых в свою очередь создаются физические. При отсылке физических пакетов, каким-либо транспортом, физические пакеты уничтожаются, тогда как виртуальные пакеты и очередь на отсылку сохраняется до прихода пакета с подтверждением успешного приема. Операция «Отменить» приводит к удалению виртуальных пакетов, но не приводит к очистке очереди на отсылку, соответственно, на следующем цикле опроса очереди на отсылку виртуальные пакеты будут созданы заново. Операция «Уничтожить» приводит к полной очистке очереди на отсылку и уничтожению виртуального пакета.
    Реализован механизм пересылки пакетов с информацией о факте удаления информационного объекта и обработки их при приеме как команды на удаление объекта. Реализована поддержка пересылки таких пакетов для типов «карточка» и документы (всех типов).
    Изменены таблицы истории изменений. Цель изменений - предотвращения ошибок приема информационных объектов в случаях, когда один и тот же объект принимался чаще, чем один раз в секунду.

    Карточки.
    Изменена таблица уровней складских запасов. В нее добавлены два поля – максимальный и минимальный торговый запас в днях торговли. Внесены изменения в поведение раздела карточек товара на странице «Заказ». Связь между величинами среднесуточная реализация (дневной расход), минимум (или максимум) в днях, минимум (или максимум) в количестве установлена следующим образом: При изменении среднесуточной реализации одновременно изменяется минимум (максимум) в количестве. При изменении минимума(максимума) в днях меняется минимум (максимум) в количестве. При изменении минимума(максимума)) в количестве меняется минимум (максимум) в днях. Если среднесуточная реализация равна 0, то минимум (максимум) в количестве устанавливается в 0 и не может быть изменен.
    Добавлена страница истории изменения уровня торговых запасов в днях торговли.
    Процедура расчета среднесуточной реализации адаптирована к новому формату таблицы уровней складских запасов. Процедура потеряла возможность настройки – изменять или нет уровни торговых запасов (в количестве). Теперь уровень торговых запасов в днях всегда неизменен, а в количестве всегда пересчитывается.






    Сервер отчетов.
    Инструкция по созданию сервера отчетов
    Глобальное именование баз данных.
    Первоначальное создание сервера отчетов
    Настройка сетевого окружения ORACLE.
    Загрузка лицензии торовой системы.
    Проверка работоспособности распределенной среды.
    Создание оперативного сервера (модуль администратора)
    Создание сервера отчетов (модуль администратора)
    Инструкция по обновлению информации сервера отчетов
    Перевод сервера отчетов в оперативный режим
    Изменение версии сервера отчетов

    Сервер отчетов


    Целью создания отдельного сервера отчетов является повышение общей производительности торговой системы путем деления нагрузки между несколькими компьютерами. На оперативном сервере обрабатывается текущий документооборот торговой организации (ввод, изменение, удаление документов и т.д.), и формируются оперативные отчеты, связанные с текущим состоянием системы. На сервере отчетов производится расчет товародвижения и подготовка любых не оперативных отчетов, то есть таких отчетов, которые обычно выполняются за период по дату, отличную от текущей даты. Сервер отчетов поддерживает актуальность данных на момент последней синхронизации двух серверов. Периодичность синхронизации определяется потребностью пользователей.
    Дополнительно, сервер отчетов может выполнять функции резервного сервера. Т.е. при выходе из строя оперативного сервера, сервер отчетов может быть переведен в оперативный режим.

    Инструкция по созданию сервера отчетов


    Реализация сервера отчетов опирается на использование snapshot-репликации, когда часть таблиц на сервере отчетов заменяется снимками таблиц оперативного сервера. Триггеры и ограничения, связанные с таблицами, заменяемыми снимками, на сервере отчетов отключаются. Снимки на сервере отчетов обновляются по требованию администратора. Снимки небольших по объему таблиц обновляются целиком, а снимки больших – инкрементально. Для инкрементального обновления снимков больших таблиц на оперативном сервере создаются журналы изменений реплицируемых таблиц.
    Оперативный сервер и сервер отчетов представляют собой распределенную систему баз данных (Distributed Database Systems). Такую систему проще эксплуатировать, если включена поддержка глобальных имен. Кроме того, Oracle Corporation рекомендует использовать глобальные имена из-за того, что множество различных компонент, включенных в Oracle Advanced Replication, требуют глобального именования баз данных.

    Глобальное именование баз данных


    Каждая база данных в распределенной системе уникально идентифицируется глобальным именем. Глобальное имя базы данных состоит из имени базы и имени домена сети, в котором находиться сервер. Для поддержки глобальных имен необходимо в файле параметров экземпляра установить значение параметра GLOBAL_NAMES равным TRUE. Там же необходимо установить значения параметров DB_NAME (имя базы данных) и DB_DOMAIN (имя домена).
    Для того чтобы проверить правильность информации о глобальном имени, хранимой в словаре базы данных, необходимо, подключившись к базе данных как SYSTEM, выполнить следующий запрос:
    select * from GLOBAL_NAME;
    При необходимости откорректировать эту информацию можно следующей командой:
    alter database rename GLOBAL_NAME to DbName.DomainName;
    где DbName – имя базы данных, а DomainName – имя домена.

    Первоначальное создание сервера отчетов


    Сервер отчетов – это физически отдельный компьютер с установленным на нем программным обеспечением сервера баз данных ORACLE и собственно базой данных сервера отчетов.
    Внимание! Версия и издание СУБД ORACLE оперативного сервера и сервера отчетов должны совпадать.
    Первоначально сервер отчетов создается путем копирования файлов базы данных торговой системы с оперативного сервера на сервер отчетов. Предварительно работа оперативного сервера должна быть корректно завершена (SHUTDOWN NORMAL или IMMEDIATE). Затем необходимо создать экземпляр базы данных сервера отчетов на основе скопированных файлов.
    Подробно процесс копирования и переименования базы данных описан в отдельной инструкции. После завершения копирования должны выполняться следующие условия: должны существовать два компьютера, подключенные к одной локальной вычислительной сети, на компьютерах должно быть установлено одинаковое программное обеспечение сервера баз данных ORACLE и должны быть размещены идентичные по содержанию базы данных с различными глобальными именами.

    Настройка сетевого окружения ORACLE


    Вариантов настроек очень много. Однако чаще всего для разрешения сетевых имен используется файл TNSNAMES.ORA, который и надо отредактировать. Главное - должна быть обеспечена возможность подключения клиента ORACLE со стороны сервера отчетов к серверу базы данных оперативного сервера и возможность подключения пользователей к серверу отчетов.
    Проверить правильность разрешения сетевого имени клиентом ORACLE можно с помощью следующей команды:
    TNSPING DB
    где DB – имя (alias), используемое для доступа к базе данных.
    Для проверки возможности подключения лучше использовать SQLPLUS, реально подключившись пользователем SUPERMAG к базе данных.

    Загрузка лицензии торговой системы


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

    Проверка работоспособности распределенной среды


    Описанные в данном параграфе действия можно проделать с использованием административного модуля торговой системы (описано дальше как создание связи). Команды SQL приводятся для пояснения выполняемых действий и могут быть полезны при возникновении проблем.
    На сервере отчетов, в схеме пользователя SUPERMAG создается связь (Database Link), которая связывает его со схемой пользователя SUPERMAG оперативного сервера и обеспечивает доступ к данным этого сервера. При включенной поддержке глобальных имен требуется, чтобы база данных имела глобальное имя, совпадающее с именем связи на нее. Например, если база данных оперативного сервера имеет имя main.shop.ru, а сервера отчетов - report.shop.ru, то связь сервера отчетов с оперативным сервером должна называться main.shop.ru.
    Для проверки правильности настроек, сделанных ранее, нужно создать связь сервера отчетов с оперативным сервером и использовать эту связь в запросе на стороне сервера отчетов для получения информации с оперативного сервера.
    Связь создается следующей командой:
    CREATE DATABASE LINK DBLinkNameCONNECT TO "SUPERMAG" IDENTIFIED BY "PassWord" USING 'DB'
    где
    DBLinkName – имя связи сервера отчетов с оперативным сервером;
    PassWord – пароль пользователя SUPERMAG;
    DB – имя (alias), используемое для доступа к базе данных оперативного сервера со стороны сервера отчетов.
    Список связей, доступных пользователю, можно посмотреть, выполнив следующий запрос:
    select * from ALL_DB_Links
    Связь проверяется выполнением следующего запроса на сервере отчетов:
    select * from DUAL@DBLinkName
    где DBLinkName – имя связи сервера отчетов с оперативным сервером.
    Удалить связь можно с помощью следующей команды:
    DROP DATABASE LINK DBLinkName
    где DBLinkName – имя связи сервера отчетов с оперативным сервером.

    Конфигурация системы: оперативный сервер – сервер отчетов


    Все таблицы торговой системы разделены на три логических списка:
  • Таблицы, обновление которых на сервере отчетов не предусматривается.
  • Таблицы, обновляемые целиком.
  • Таблицы, обновляемые инкрементально.


Отключение ряда таблиц от обновления позволяет иметь независимые данные на двух серверах, то есть такие данные, которые при обновлении на оперативном сервере не подвергаются изменению на сервере отчетов. В перечень не обновляемых таблиц входят таблицы расчета товародвижения, таблицы для настройки прав доступа пользователей к торговой системе и все временные таблицы. Обновляемые таблицы могут редактироваться только на оперативном сервере.
Использование инкрементальной репликации позволяет сократить время обновления за счет некоторого замедления оперативной работы (из-за потерь на запись в журналы изменений).
Для инкрементального обновления снимков больших таблиц на сервере отчетов на оперативном сервере создаются журналы изменений реплицируемых таблиц. Все действия по созданию журналов производятся процедурой Create_Logs пакета Replic, которая выполняют работу на основании содержимого настроечной таблицы SSReplic.
В таблицу SSReplic помещаются списки имен таблиц, которые не должны реплицироваться или должны реплицироваться инкрементально. Все постоянные таблицы, имена которых не отражены в этой таблице, будут реплицироваться путем полного обновления, все временные таблицы не будут реплицироваться. Полный список таблиц схемы базы данных получается из системных таблиц Oracle.
Строка таблицы SSReplic содержит два поля: имя мастер таблицы (NAME) и тип создаваемого снимка (SNAPTYPE). Если какую либо реплицируемую таблицу надо обновлять инкрементально, то ее имя надо поместить в SSReplic, указав 'F' (Fast) в поле типа снимка. Если же какую либо таблицу не надо реплицировать, то ее имя надо поместить в SSReplic, указав NULL в поле типа снимка.
Содержание таблицы используется в момент создания сервера отчетов. В дальнейшем изменение содержания таблицы не оказывает влияния на поведение механизма репликации.

Создание оперативного сервера (административный модуль)


Для создания журналов изменений, используемых при обновлении снимков больших таблиц, необходимо подключиться к оперативному серверу с помощью администратора торговой системы, нажать кнопку 'Сервер отчетов' на закладке 'Утилиты' раздела 'База данных'. Откроется одноименный диалог (рис. 1). В этом диалоге необходимо нажать кнопку 'Оперативный сервер'.
Непосредственно перед созданием журналов, в отдельном окне (рис. 2) будет предложено указать название табличного пространства для их размещения. Если оставить поле не заполненным, то журналы будут созданы в табличном пространстве, назначенном пользователю SUPERMAG по умолчанию. Однако настоятельно рекомендуется создать и использовать отдельное табличное пространство для хранения информации журналов изменений. При использовании отдельного табличного пространства для журналов, пользователь SUPERMAG должен иметь права (квоту) на использование этого пространства.


рис. 1

рис. 2
Создание журналов возможно, если пользователь имеет права на функциональную роль SUPERMAG_FN_REPLICFULL – 'Полное управление сервером отчетов'.

Создание сервера отчетов (административный модуль)


Для создания сервера отчетов необходимо подключиться к нему с помощью администратора торговой системы и нажать кнопку 'Сервер отчетов' на закладке 'Утилиты' раздела 'База данных'. Откроется одноименный диалог (рис. 1).
Сначала, если это не было сделано ранее, надо в схеме пользователя SUPERMAG на сервере отчетов создать связь (Database Link), которая свяжет его со схемой пользователя SUPERMAG оперативного сервера и обеспечивает доступ к данным этого сервера. Для этого в диалоге 'Сервер отчетов' (рис. 1) в разделе DBLink необходимо нажать кнопку 'Создать' и заполнить поля диалога 'Создание связи' (рис. 3).
В диалоге 'Создание связи' указывается:
Строка связи TNS – имя (alias) для доступа к базе данных оперативного сервера;
Пароль пользователя SUPERMAG – пароль на оперативном сервере;
Наименование связи – имя связи сервера отчетов с оперативным сервером.
При использовании поддержки глобальных имен, имя связи должно совпадать с глобальным именем базы данных оперативного сервера.

рис. 3


Далее, в диалоге 'Сервер отчетов' необходимо нажать кнопку 'Сервер отчетов'. В результате часть таблиц на сервере отчетов заменится на снимки таблиц оперативного сервера. Триггеры и ограничения, связанные с таблицами, заменяемыми снимками, на сервере отчетов отключаются. Создание снимков производится процедурой Create_Snapshots пакета Replic, которая выполняют работу на основании содержимого настроечной таблицы SSReplic на оперативном сервере. В этой таблице хранится перечень не реплицируемых таблиц.
Создание снимков возможно, если пользователь имеет права на функциональную роль SUPERMAG_FN_REPLICFULL – 'Полное управление сервером отчетов'.
Затем администратор должен выполнить прикладные настройки торговой системы на сервере отчетов. Он должен отредактировать список пользователей и настроить их права.

Инструкция по обновлению информации сервера отчетов


Периодически сервер отчетов должен синхронизироваться с оперативным сервером. При этом происходит обновление информации, содержащейся в большинстве таблиц. Информация в таблицах, содержащих локальные настройки и результаты расчетов, не изменяется.
Обновление информации на сервере отчетов возможно, если пользователь имеет права на функциональную роль SUPERMAG_FN_REPLICFULL – 'Полное управление сервером отчетов' или SUPERMAG_FN_REPLICREFRESH – 'Обновление информации на сервере отчетов'.
Обновление информации на сервере отчетов должно проводиться в такое время, когда другие пользователи торговой системы не работают. В торговой системе нет механизмов блокировки доступа рядовых пользователей во время обновления информации на сервере отчетов и этот вопрос должен решаться административно.
Для обновления информации необходимо подключиться к серверу отчетов с помощью административного модуля торговой системы и нажать кнопку 'Сервер отчетов' на закладке 'Утилиты' раздела 'База данных'. Откроется одноименный диалог (рис. 1). В этом диалоге необходимо нажать кнопку 'Синхронизация'.

рис. 1
Дополнительно, до начала синхронизации можно убедиться в работоспособности связи сервера отчетов с оперативным сервером. Для этого в разделе DBLink необходимо нажать кнопку 'Проверить'.
Непосредственно перед началом синхронизации, в отдельном окне (рис. 2) будет предложено указать название сегмента отката (rollback segment), используемого при обновлении снимков. Если оставить поле не заполненным, то будет использован очередной (следующий по порядку) сегмент. Однако, если объемы изменений велики, то размеров стандартных сегментов отката может быть не достаточно. В таком случае администратору сервера следует создать отдельный сегмент отката больших размеров и указывать его в качестве рабочего при обновлении снимков.


рис. 2
Об успешном завершении синхронизации можно судить по содержимому поля 'Время последней синхронизации: завершение'. При успешном завершении оно содержит дату и время завершения синхронизации, а при завершении синхронизации из-за ошибки поле содержит строку 'UNDEFINED' (неопределенный). При возникновении ошибок в процессе синхронизации, операцию синхронизации необходимо повторить.

Перевод сервера отчетов в оперативный режим


Сервер отчетов может выполнять функции резервного сервера. Т.е. при выходе из строя оперативного сервера, сервер отчетов может быть переведен в оперативный режим. Однако необходимо учитывать, что данные, внесенные в оперативный сервер после его последней синхронизации с сервером отчетов, будут потеряны.
Перевести сервер отчетов в оперативный режим возможно, если пользователь имеет права на функциональную роль SUPERMAG_FN_REPLICFULL – 'Полное управление сервером отчетов'.
Для перевода сервера отчетов в оперативный режим необходимо подключиться к серверу отчетов с помощью административного модуля торговой системы и нажать кнопку 'Сервер отчетов' на закладке 'Утилиты' раздела 'База данных'. Откроется одноименный диалог (рис. 1). В этом диалоге необходимо нажать кнопку 'Единственный сервер'.

рис. 1
Процедуры перевода сервера отчетов в оперативный режим реализованы таким образом, что если процесс будет прерван какой-либо ошибкой (например, недостаточно свободного места в табличном пространстве), то после устранения причин, вызвавших ошибку, операцию можно повторить.
Примечание.
Процесс перевода сервера в оперативный режим является ресурсоемким по отношению к таблицам, не имеющим первичного ключа. Если таблица, не имеющая первичного ключа, содержит большой объем данных, то для ее преобразования требуется время на перенос данных. Кроме того, необходимо свободное место в табличном пространстве, равное пространству, занимаемому таблицей. В настоящее время потенциально узким местом является таблица SMSpecScale, которая не имеет первичного ключа и в будущем может содержать большой объем информации.

Изменение версии сервера отчетов


Для изменения версии программного обеспечения торговой системы или для установки Сервис Пака необходимо выполнить следующие действия:

  1. синхронизировать сервер отчетов с оперативным сервером;
  2. перевести сервер отчетов в оперативный режим;
  3. изменить версию программного обеспечения как на компьютере с оперативным сервером, так и на компьютере с сервером отчетов, находящемся в оперативном режиме;
  4. перевести сервер отчетов из оперативного режима в режим сервера отчетов.


Возможен и такой вариант действий, когда модифицируется программное обеспечение только на оперативном сервере, а сервер отчетов создается заново.
Примечание.
Можно также рекомендовать до начала изменения версии удалять поддержку сервера отчетов с оперативного сервера (удалять журналы изменений). Это делается аналогично переводу сервера отчетов в оперативный режим. Операция - не ресурсоемкая и выполняется быстро. В этом случае после изменения версии надо восстановить поддержку сервера отчетов на оперативном сервере, как описано в инструкции по созданию сервера отчетов.


Сравнение структуры базы данных с эталоном

Все тесты проводятся в два этапа. На первом этапе загружается эталонное описание структуры схемы SUPERMAG базы данных. На втором этапе проводится сравнение эталонного описания с текущей структурой базы данных и формирование отчета.

Объекты

Данный тест наиболее общий. Проверяются все объекты в схеме SUPERMAG. Это: таблицы, индексы, представления, процедуры, функции, пакеты, триггеры и последовательности. Проверяется как отсутствие объектов, так и наличие лишних объектов.
Сопоставление проводится по имени и типу объекта. Не рассматриваются объекты, имя которых начинается со строки "SYS_".

Колонки таблиц

Проверяется наличие всех колонок, которые есть в эталонном описании. Поиск колонки проводится по имени таблицы или представления и имени колонки. Если колонка присутствует, то у нее дополнительно проверяется признак обязательности (not NULL), тип данных и размерность.
Отдельно проверяется наличие лишних (т.е. отсутствующих в эталонном описании) обязательных колонок. Информация о лишних необязательных колонках не выводиться, т.к. они не влияют на работоспособность системы.

Ограничения

Проверяется наличие всех ограничений, которые есть в эталонном описании. Поиск ограничения проводиться по его характеристикам (таблица, тип, параметры). Дополнительно проверяется имя ограничения. Если оно не совпадает с указанным в эталоне, и указанное в эталоне имя не начинается со строки "SYS_", то в отчет выводиться предупреждающее сообщение.
Следует отметить, сто проверка ограничений типа CHECK не строгая, т.к. правило, заданное в ограничении, в силу особенностей его хранения в ORACLE, подвергается преобразованию. Кроме того, не проводиться никакой предметный анализ этого правила, и проверка проходит достаточно формально. Например, правила "A>B" и "B<A" будут считаться разными. Правила "A>B" и "A > B" будут считаться одинаковыми, но "A='ab'" и " A='a b'" так же будут считаться одинаковыми.
Отдельно проверяется наличие лишних ограничений. При этом проверяются только CHECK и REFERENTIAL INTEGRITY, т.к. лишние первичные и уникальные ключи можно отследить по уникальным индексам.

Индексы

Проверяются только уникальные индексы, т.к. создание или удаление других с одной стороны не должно сказаться на работоспособности СУПЕРМАГа, а с другой стороны не исключается при проведении оптимизации конкретной базы данных ее администратором.
Индексы идентифицируются не по имени индекса, а по имени таблицы и перечню ее колонок, входящих в индекс.
Лишние уникальные индексы контролируются только у таблиц, присутствующих в эталонном описании, т.к. при эксплуатации СУПЕРМАГа пользователями могут быть созданы новые таблицы, но их уникальные индексы не влияют на работоспособность системы. Создание пользователями своих таблиц в схеме SUPERMAG не рекомендуется, и информацию о таких таблицах можно получить в тесте 'Объекты'.


Супермаг Мобайл.


Версии программы.
Установка программы Супермаг Мобайл.
Начало работы.
Настройка соединения с сервером приложений.
Выбор вида работы.
Инвентаризация.
Закладка «Инвентаризация».
Закладка «Журнал».
Закладка «Спецификация».
Закладка «Завершение».
Контроль остатков.
Закладка «Инвентаризация».
Закладка «Журнал».
Закладка «Спецификация».
Закладка «Завершение».
Прием товара по заказу.
Закладка «Прием».
Закладка «Журнал».
Закладка «Спецификация».
Закладка «Завершение».
Контроль ценников.
Закладка «Контроль».
Закладка «Журнал».
Закладка «Завершение».

Версии программы.


Версии программы Супермаг Мобайл имеют номер, состоящий из четырех групп цифр, например:
1.0.13.30
Первые две группы цифр означают номер версии программы, две следующие группы цифр – номер сборки.
Номер версии меняется в тех случаях, когда в программе Супермаг Мобайл появляются такие изменения, которые требуют адекватных изменений в программе Супермаг+, например, новые режимы работы программы или расширение протокола обмена данными. При смене версии программы Супермаг Мобайл в документации к версии указывается минимальная версия программы Супермаг+, с которой указанная версия будет работать корректно.
Смена номера сборки означает внесение изменений, не предъявляющих новых требований к версии программы Супермаг+.
Структура хранения дистрибутивов программы Супермаг Мобайл будет содержать только последние сборки для каждой версии программы.

Установка программы Супермаг Мобайл.


Программа Супермаг Мобайл может работать в среде ОС Windows CE и Windows Mobile 6.1 (6.5) на устройствах со встроенным сканером (Терминал Сбора Данных).
Для установки программы могут быть использованы следующие программы установки:
Sm.Mobile.Terminal.EXE
SmMobileTerminalSetup.CAB
Программа Sm.Mobile.Terminal.EXE запускается в среде ОС Windows XP/Vista/7 на компьютере, у которого имеется USB-разъем. Мобильное устройство в этом случае должно быть установлено в крэдл, подключенный к USB-порту компьютера.
Программа SmMobileTerminalSetup.CAB исполняется непосредственно на мобильном устройстве. Для этого файл предварительно должен быть скопирован в каталог мобильного устройства и далее запущен на нем средствами ОС мобильного компьютера.
При выполнении программы установки необходимо выбрать каталог мобильного устройства, в котором будет установлена программа Супермаг Мобайл. По умолчанию, для установки предлагается каталог «Program Files \ Service Plus SMT.Mobile \ SM.Mobile.Terminal». Необходимо заменить корневой каталог установки «Program Files» на каталог «Flash Dick» для того, чтобы поместить программу и ее внутреннюю базу данных в энергонезависимую память. В противном случае, при полном разряде батареи все данные и сама программа будут утеряны.
В процессе установки в каталог SM.Mobile.Terminal вместе с файлами программы Супермаг Мобайл устанавливается файл программы Sm.Restore.Terminal.exe - программа восстановления настроек ТСД после холодного рестарта. Программа восстановления работает на ТСД М3 и на тех ТСД, в которых предусмотрен автоматический старт программ из скрытого каталога Flash Dick \ Startup в ходе холодного старта устройства. Программа восстанавливает настройки WiFi-модуля, настройки громкости звуковых сигналов, иконку программы Супермаг Мобайл на рабочем столе и данные программы Супермаг Мобайл, хранимые в системном реестре.
Программа восстановления активируется при первом старте Супермаг Мобайл. Если устройство разрядится или будет нажата кнопка холодного рестарта до первого запуска программы Супермаг Мобайл, восстановления данных не произойдет.
Если, по каким-либо причинам, действие программы восстановления нежелательно, то файл программы необходимо вручную удалить из каталога Flash Dick \ Startup.

Начало работы.


Программа Супермаг Мобайл получает и возвращает данные программе-источнику - Супермаг+ - по локальной сети. Программа «Сервер приложений» Супермаг+ выступает в роли сервера, программа Супермаг Мобайл выступает в роли клиента. Для установления соединения между двумя программами в программе Супермаг Мобайл необходимо указать IP-адрес компьютера, на котором работает служба сервера приложения Супермаг+. Порт компьютера сервера указывать не надо. Порт для обмена данными фиксированный: 63405.
Чтобы сервер приложений Супермаг+ ожидал сигнал от программы Супермаг Мобайл, необходимо в администраторе сервера приложений открыть диалог «Настройка общих параметров» и включить флаг «Разрешить подключение терминалов сбора данных SuperKit Mobile» и заново стартовать сервер приложений.
Мобильное устройство может обращаться к другим компьютерам либо при использовании беспроводного (WiFi) соединения с локальной сетью, либо с помощью кредла, подключенного к USB-порту компьютера.
Для использования беспроводного соединения необходимо, чтобы в сети функционировал WiFi-роутер, и чтобы мобильное устройство находилось в зоне его действия. В самом мобильном устройстве необходимо настроить соединение с WiFi-роутером и убедиться в наличии устойчивой связи. В этом случае устройство может обмениваться данными с любым компьютером локальной сети.
При подключении мобильного устройства к компьютеру через крэдл, устройство также может обмениваться данными по сетевому протоколу, но только с тем устройством, к которому оно подключено. Это означает, что если, например, устройство подключить к клиентскому компьютеру, находящемуся в сети, и сервер приложений будет работать на другом компьютере этой сети, то, с точки зрения мобильного устройства, компьютер сервера приложений будет недоступен.
При работе с WiFi-соединением необходимо учитывать, что при «засыпании» мобильного устройства, WiFi-модуль устройства отключается, и при последующей его активизации восстановление беспроводного соединения занимает от нескольких секунд до десятков секунд. В этот промежуток времени обмен между мобильным устройством и сервером приложений невозможен и при работе с программой могут появляться сообщения «Нет сети, компьютер <IP-адрес> выключен или недоступен из данного места сети». При появлении такого сообщения необходимо выждать некоторое время и повторить действие.

Настройка соединения с сервером приложений.


При старте программы Супермаг Мобайл отображается окно «Соединение с сервером приложений».
Если программа запущена впервые, элемент диалога «Сервер» не заполнен и дальнейшая работа программы невозможна. Для начала работы программы, а также при каждом перемещении мобильного устройства между разными локальными сетями, например, при перемещении в другой магазин с другой локальной сетью, необходимо задать адрес компьютера сервера приложения и настроить параметры работы с ним. Для этого необходимо нажать кнопку «…».


В окне «Выбор сервера приложений» необходимо указать IP-адрес компьютера, на котором работает сервер приложений, и нажать кнопку «Тест». При тестировании соединения с сервером приложения у сервера запрашивается список активных баз данных и для каждой активной базы данных - список локальных мест хранений.
Список баз данных помещается в выпадающий список «База данных», и если список состоит из единственной записи, она подставляется в окно списка в качестве выделенной. При выборе базы данных выпадающий список мест хранения заполняется списком её локальных мест хранения, и если такое место хранение одно, оно сразу подставляется в качестве выбранного места хранения.
Базу данных и место хранения необходимо задать обязательно. В дальнейшем вся работа программы ТСД будет проходить с указанной базой данных и местом хранения. Перенастройка этих параметров означает полный сброс всех накопленных данных программы ТСД.
При выходе из окна «Выбор сервера приложений» данные о списке доступных баз данных и списках локальных мест хранения, помимо выбранных для работы, теряются. В случае необходимости сменить базу данных и / или место хранения, необходимо снова нажать кнопку «Тест» и перечитать актуальные списки.

При последующих запусках программы Супермаг Мобайл параметры соединения, выбранные на предыдущем шаге, будут показываться в окне «Соединение с сервером приложений» и будут использованы для соединения с сервером.
Далее, для работы с программой надо ввести имя пользователя и пароль и нажать кнопку «Старт»:
Имя пользователя запоминается и при последующих стартах программы может быть выбрано из выпадающего списка. Пароль необходимо вводить заново при каждом старте программы.
Имя и пароль пользователя заранее должны быть зарегистрированы администратором Супермаг+ (Административный модуль, раздел «Права доступа», закладка «Сотрудники»).

Поскольку клавиатура мобильного устройства имеет ограниченные возможности, а виртуальная клавиатура не обладает необходимой эргономичностью, то имя и пароль сотрудника желательно создавать с использованием только цифр и латинских букв. Должности сотрудника необходимо выдать права на тот раздел Супермаг+, который соответствует его задаче (Административный модуль, раздел «Права доступа», закладка «Должности»). Это могут быть разделы «Инвентаризация ТСД», «Контроль остатков ТСД», «Прием товара по заказу ТСД» или «Контроль ценников ТСД».

Выбор вида работы.


Программа Супермаг Мобайл имеет четыре режима работы: «Инвентаризация» и «Контроль остатков», «Прием товара по заказу», «Контроль ценников». Каждый режим работы соответствует своему виду деятельности и работает со своим набором данных. При прерывании работы данные, накопленные в ходе работы, не теряются и могут быть использованы для продолжения работы. Но при смене режима работы данные, накопленные в другом режиме работы и не переданные на сервер, будут удалены после соответствующего предупреждения. Программа не предусматривает поддержку нескольких параллельных видов работ. Каждая работа должна быть завершена и ее данные должны быть переданы на сервер, прежде чем можно приступить к следующей работе.
Режим «Инвентаризация» предназначен для подсчета фактических остатков товара в ходе сплошной инвентаризации места хранения. Инвентаризация может выполняться одним или более оператором без выделения оператору строгого списка проверяемых товаров. Под строгим списком проверяемых товаров подразумевается способ проведения инвентаризации, при котором оператор не имеет права подсчитывать товар, им обнаруженный, но не относящийся к его зоне ответственности.
Инвентаризация завершается созданием бухгалтерского учетного документа – сличительной ведомости и накладными на списание недостачи и зачисление излишков.

В этом режиме ТСД выступает в роли отдельного счетчика, результаты работы которого могут быть зафиксированы в инвентаризационной описи или, если счетчик один, сразу в сличительной ведомости. Создание учетных документов осуществляется в программе Супермаг+ в экземпляре процесса «Инвентаризация ТСД». Экземпляр процесса создается в момент передачи данных завершенного задания инвентаризации из программы ТСД на сервер. Один экземпляр процесса соответствует одному заданию одного устройства. В случае проведения инвентаризации несколькими счетчиками, результаты инвентаризации объединяются в одну сличительную ведомость после того, как будут созданы инвентаризационные описи, каждая из которых создается одним экземпляром процесса «Инвентаризация ТСД». В этом случае инвентаризационные описи должны создаваться с одним и тем же номером приказа об инвентаризации и собственным контрагентом.
Режим «Контроль остатков» предназначен для проведения частичной или выборочной инвентаризации и для коррекции значения текущих складских остатков, которые используются для управленческих целей, в частности, для оценки потребности в товаре и при заказе товара. В результате оперативной инвентаризации создаются документы «Акт потерь» и «Акт обнаружений». Создание документов осуществляется в программе Супермаг+ в экземпляре процесса «Контроль остатков ТСД». Экземпляр процесса создается в момент передачи данных завершенного задания из программы ТСД на сервер.
Для обеспечения выборочной инвентаризации в программу ТСД загружается список товаров, относящийся к заданным группам товаров или номенклатур, либо к заданным зонам инвентаризации (см. раздел «Планограмма») или к отдельным элементам планограммы торгового зала. Товары, не входящие в список инвентаризации, не учитываются в журнале инвентаризации.
Информация об артикулах в режиме оперативной инвентаризации содержит данные о цене товара и оперативно доступном остатке товара. Сведения об остатке позволяют обратить внимание оператора на необходимость дополнительных усилий для поиска товара, если его количество оказалось меньше ожидаемого.
Режим «Прием товара по заказу» предназначен для регистрации поставки товара с контролем соответствия количества поставляемого товара и количества заказанного товара и с контролем соответствия цены поставки и цены заказа с учетом допустимых отклонений, зафиксированных в контракте с поставщиком. В результате выполнения работы будет создан документ «Приходная накладная» в статусе «принят складом». Создание документа осуществляется в экземпляре процесса «Прием товара по заказу ТСД». Экземпляр процесса создается в момент передачи данных завершенного задания из программы ТСД на сервер.
Режим «Контроль ценников» предназначен для проверки соответствия цены артикула в ценниках и его текущей цены для кассы. В процессе работы оператор отмечает артикулы, для которых необходимо напечатать новые ценники с учетом их категории. Результаты работы оператора передаются на сервер в экземпляр процесса «Контроль ценников ТСД», в котором вызывается процедура печати новых ценников.

Инвентаризация.


В режиме «Инвентаризация» перед началом работы или в ходе работы по беспроводному соединению программа ТСД получает следующие данные о товарах: артикулы, название и штриховые коды. Информация о ценах и остатках товаров в этом режиме в программу ТСД не передается.

Перед началом загрузки информации об артикулах предлагается выбрать вариант загрузки в экране «Параметры загрузки товаров».
При выборе опции «Загружать все товары» в программу ТСД передаются данные всех артикулов. В случае большого количества артикулов это может занять значительное время.
При выборе опции «Загружать товары только с ненулевым остатком» в ТСД передаются только артикулы с ненулевым остатком. Этот вариант можно использовать, если зона покрытия беспроводной связи обеспечивает достаточно полное покрытие зоны инвентаризации. При загрузке в ТСД только артикулов с ненулевым остатком в ТСД будет сформирован список артикулов, вероятность обнаружения которых максимальна.


Вариант работы без предварительной загрузки артикулов не предусмотрен, поскольку предварительная загрузка значительно уменьшает время реакции на сканирование штрихового кода и снижает риск перерывов в работе при неустойчивой работе беспроводного соединения.
Если в процессе работы будет просканирован неизвестный штриховой код, программа ТСД запросит с сервера информацию об артикуле по считанному штриховому коду и, при успешном его обнаружении, добавит его в рабочий список артикулов.
Все просканированные штриховые коды, как для опознанных артикулов, так и для неопознанных, сохраняются в журнале инвентаризации и, в дальнейшем, после завершения задания, передаются на сервер. В ходе дальнейшей обработки результатов инвентаризации в интерфейсе процесса можно провести работу по выяснению соответствия неопознанных штриховых кодов и артикулов товара.
После выбора варианта загрузки и нажатия на кнопку «Ввод» начнется загрузка данных о товарах.

После загрузки данных будет показано окно начала новой инвентаризации с текущим заданием. Для того чтобы приступить к работе надо нажать на кнопку «Да». При нажатии на эту кнопку фиксируется время начала работы и осуществляется переход к экрану «Инвентаризация».

Если на этом этапе, то есть уже в ходе работы по инвентаризации, прекратить работу с программой (нажать кнопку «Выход»), то при последующем старте программы будет предложено продолжить инвентаризацию. Время начала работы и все собранные данные будут сохранены. Если продолжение инвентаризации не имеет смысла, необходимо отказаться от ее продолжения и сформировать задание снова.

Закладка «Инвентаризация».


Закладка для сканирования или ручного ввода штрихового кода товара и количества упаковок. Если сканирование штрихового кода происходит при нахождении на другой закладке рабочего режима, автоматически будет осуществлен переход на закладку «Инвентаризация» и предоставлена информация о сканируемом товаре.

На закладке «Инвентаризация» показывается следующая информация:

  • Количество сканирований - количество последовательных сканирований одного и того же штрихового кода или, что тоже самое, количество упаковок или штук товаров, соответствующих данному штриховому коду.
    Количество сканирований накапливается при последовательном сканировании одного и того же штрихового кода или может быть введено вручную. Для ручного ввода количества сканирований достаточно ввести число с клавиатуры ТСД. Фокус ввода предварительно устанавливается в элементе количества сканирований.
    При сканировании другого штрихового кода накопленная информация сохраняется в журнале сканирований, и подсчет сканирований начинается снова с 1.
    При сканировании весового штрихового количество сканирований всегда равно 1 и не может быть изменено. При сканировании следующего штрихового кода информация о предыдущем сканировании немедленно сохраняется в журнал, и количество сканирований не увеличивается, даже если сканируется тот же товар с тем же весом.
    Если будет просканирован или введен штриховой код товара, данные о котором отсутствуют в программе ТСД и не могут быть предоставлены сервером, результат сканирования попадет в журнал с пустым значением артикула.
  • Количество в упаковке – количество товара в упаковке, соответствующей штриховому коду. Для весового товара это количество берется из штрихового кода этикетки.
  • Количество – произведение количества сканирований на количество в упаковке, то есть количество товара, подсчитанное в текущей сессии сканирований.
  • Всего количество посчитанное – общее количество данного товара (артикула), посчитанное в ходе сверки, включая подсчеты с иными штриховыми кодами данного артикула.
  • Комментарий – поле для ввода текста комментария, в случае если штриховой код товара не найден.
    При сканировании штрихового кода, если информация по штриховому коду ранее не была получена программой, программа обращается к серверу приложений, и при отсутствии беспроводного соединения будет выдано сообщение о том, что сеть недоступна. В случае если сеть недоступна по объективным причинам, можно отказаться от получения сообщения о недоступности сети, чтобы не отвлекаться на эти сообщения.
    Закладка «Журнал».


    На закладке показывается история сканирований с расположением записей в порядке, обратном хронологии. То есть, самое последнее сканирование показывается в первой записи таблицы. Журнал можно редактировать. При ошибочном сканировании можно удалить запись из журнала или скорректировать запись.
    В нижней части страницы отображается детальная информация по выбранной строке таблицы – название артикула и его общее посчитанное количество.
    При изменении записи журнала можно изменить количество сканирований (упаковок, штук) для штучных товаров и комментарий для неопознанных штриховых кодов. Для весовых товаров коррекция количества сканирований невозможна.

    Закладка «Спецификация».
    На закладке показывается список артикулов, обнаруженный в процессе инвентаризации и их подсчитанное количество «КолФ». Записи выводятся в алфавитном порядке названия артикула.
    Артикулы товаров, штриховые коды которых не присутствуют в журнале инвентаризации, в спецификации не показываются. Обработка данных товаров, которые не обнаружены в процессе инвентаризации, но имеют не нулевой остаток, производится в Торговой системе.

Закладка «Завершение».




На закладке показывается содержание задания на полную инвентаризацию и кнопка завершения работы. При нажатии на кнопку «Завершить инвентаризацию» фиксируется время окончания работы и блокируется возможность дальнейшего подсчета товаров. Далее можно только передать данные на сервер или выйти из программы. При выходе из программы до передачи данных на сервер, накопленные данные будут сохранены с возможностью передать их в другое время, например, если беспроводное соединение в данном месте здания не доступно. Выполнять другое задание до передачи данных на сервер не разрешается.
После успешной передачи данных, их можно удалить и приступить к следующей работе. Протокол передачи данных гарантирует, что при получении программой ТСД сигнала об успешном приеме переданных данных, все данные действительно полностью и успешно приняты сервером.

Контроль остатков.


В режиме «Контроль остатков» перед началом формирования задания необходимо выбрать вариант выбора списка товаров для инвентаризации. Список товаров может определяться по группам классификатора товаров или группам классификатора номенклатур, по зонам инвентаризации действующей планограммы торгового зала или по элементам (стеллажам, холодильным ларям и т.д.) планограммы.






В соответствии с выбранным вариантом выбора списка товаров программа ТСД запрашивает с сервера данные классификатора групп товаров, номенклатур или планограммы.
Далее необходимо сформировать задание путем выбора необходимого перечня групп классификатора товара, номенклатур, зон инвентаризации или элементов планограммы.
После подтверждения выбора программа запрашивает с сервера данные об артикулах товаров, входящих в состав задания: артикулы, название, штриховые коды.




В ходе инвентаризации, артикулы, не относящиеся к заданию, не попадут в журнал сканирований, и в дальнейшем не будут учитываться.
После загрузки данных показывается окно начала новой инвентаризации с описанием текущего задания. Для того чтобы приступить к работе, надо нажать на кнопку «Начать инвентаризацию». При нажатии на эту кнопку фиксируется время начала работы и с сервера считываются текущие складские остатки и цены. Под текущими складскими остатками понимаются текущие остатки по документам товародвижения в статусе «Принят/отпущен складом» и «Принят полностью» минус потери, минус оперативные продажи. Информация об остатках товаров позволяет внимательнее отнестись к тем позициям, посчитанное количество которых меньше ожидаемых складских остатков.
После считывания оперативных остатков программа переходит к закладке «Инвентаризация»

Если на этом этапе прекратить работу с программой (нажать кнопку «Выход»), то при последующем старте программы будет предложено продолжить инвентаризацию. Время начала работы и все собранные данные будут сохранены. Если продолжение инвентаризации не имеет смысла, необходимо отказаться от ее продолжения и сформировать задание снова.

Закладка «Инвентаризация».


Закладка для сканирования или ручного ввода штрихового кода товара и количества упаковок. Если сканирование штрихового кода происходит при нахождении на другой закладке рабочего режима, автоматически будет осуществлен переход на закладку «Инвентаризация» и предоставлена информация о сканируемом товаре.


На закладке «Инвентаризация» показывается следующая информация:

  • Количество сканирований - количество последовательных сканирований одного и того же штрихового кода или, что тоже самое, количество упаковок или штук товаров, соответствующих данному штриховому коду.
    Количество сканирований накапливается при последовательном сканировании одного и того же штрихового кода или может быть введено вручную. При сканировании другого штрихового кода накопленная информация сохраняется в журнале сканирований, и подсчет сканирований начинается снова с 1.
    При сканировании весового штрихового количество сканирований всегда равно 1 и не может быть изменено. При сканировании следующего штрихового кода информация о предыдущем сканировании сразу сохраняется в журнал, и количество сканирований не увеличивается, даже если сканируется тот же товар с тем же весом.
    Если будет просканирован или введен штриховой код товара, данные о котором отсутствуют в программе ТСД, будет показано сообщение о том, что товар не входит в состав задания и результаты сканирования не будут добавлены в журнал.
  • Количество в упаковке – количество товара в упаковке, соответствующей штриховому коду. Для весового товара это количество берется из штрихового кода этикетки.
  • Количество – произведение количества сканирований на количество в упаковке, то есть количество товара, подсчитанное в текущей сессии сканирований.
  • Всего количество посчитанное – общее количество данного товара (артикула), посчитанное в ходе сверки, включая подсчеты с иными штриховыми кодами данного артикула.
  • Остатки на начало – складской остаток товара на начало инвентаризации. Остатки товаров получаются с сервера в момент начала работы и в дальнейшем, в ходе работы, не перечитываются. Если оперативная инвентаризации производится без остановки торговли проверяемого товара, данная информация может быть неактуальной.
    Под складским остатком понимается остаток товара (раздел «Карточки складского учета», закладка «Остатки», поле «Остаток») с учетом потерь и оперативных продаж.
    Закладка «Журнал».




    На закладке показывается история сканирований с расположением записей в порядке, обратном хронологии. То есть, самое последнее сканирование показывается в первой записи таблицы. Журнал можно редактировать. При ошибочном сканировании можно удалить запись из журнала или скорректировать количество сканирований. Для весовых товаров количество сканирований изменить нельзя.
    В нижней части страницы отображается детальная информация по выбранной строке таблицы – название артикула и его общее посчитанное количество.
    Закладка «Спецификация».


    На закладке показывается список всех артикулов из списка инвентаризации, а не только обнаруженных. Записи отсортированы в алфавитном порядке названия артикула. В таблице показывается остаток товара на начало инвентаризации «Ост.», подсчитанное количество «КолФ» и разница «Откл». Если разница отрицательная, величина разницы показывается красным цветом.
    Внизу экрана для выделенной строки показывается отклонение фактического количества от складского остатка, розничная цена артикула и стоимость отклонения артикула.
    Закладка «Завершение».


    На закладке показывается содержание задания оперативной инвентаризации и кнопка завершения работы. При нажатии на кнопку «Завершить инвентаризацию» фиксируется время окончания работы и блокируется возможность дальнейшего подсчета товаров. Далее можно только передать данные на сервер или выйти из программы. При выходе из программы до передачи данных на сервер, накопленные данные будут сохранены с возможностью передать их в другое время, например, если беспроводное соединение в данном месте здания не доступно.
    После успешной передачи данных, их можно удалить и приступить к следующей работе.

    Прием товара по заказу.

    Для приема товаров по заказу программе ТСД необходимо иметь данные о заказах поставщикам. Данные о заказах могут быть получены заблаговременно, нажатием кнопки «Загрузить новые заказы на ТСД». В этом случае необходимо указать диапазон дат поставки заказа. По умолчанию диапазон равен трем дням в прошлое и трем дням в будущее от текущей даты. Если число дней диапазона равно 0, отбираются заказы только с поставкой на сегодня. Заказы отбираются по условию попаданию даты поставки заказа в заданный диапазон дней, с поставкой товара в то место хранения, в котором работает ТСД, и со статусом «Размещен» или «Закрыт».


    Если данные о заказах заранее не загружены, они будут запрашиваться с сервера при вводе номера заказа в окне «Ввод номера заказа». Окно вызывается кнопкой «…». Номер заказа можно считать сканером с печатной формы документа «Заказ поставщику» или ввести вручную с помощью клавиатуры ТСД.

    Для заказов показывается его статус, дата документа, дата и время поставки. Статус заказа может говорить о том, были ли поставки по данному заказу. При использовании функции автоматического закрытия заказа, заказ получает статус «Закрыт» при первой поставке по данному заказу, даже если заказ выполнен не полностью.
    Для начала работы с поставкой по заказу необходимо нажать кнопку «Выбор». В этом случае фиксируется время начала работы по приему поставки и отображается состав задания. Если в этот момент отказаться от дальнейшей работы, будет предложено начать новый прием товара по заказу.
    Закладка «Прием».

    Закладка для сканирования или ручного ввода штрихового кода товара и количества упаковок. Если сканирование штрихового кода происходит при нахождении на другой закладке рабочего режима, автоматически будет осуществлен переход на закладку «Прием» и предоставлена информация о сканируемом товаре.

    На закладке «Прием» показывается следующая информация:
  • Количество сканирований - количество последовательных сканирований одного и того же штрихового кода или, что тоже самое, количество упаковок или штук товаров, соответствующих данному штриховому коду.
    Количество сканирований накапливается при последовательном сканировании одного и того же штрихового кода или может быть введено вручную. При сканировании другого штрихового кода накопленная информация сохраняется в журнале сканирований, и подсчет сканирований начинается снова с 1.
    При сканировании весового штрихового количество сканирований всегда равно 1 и не может быть изменено. При сканировании следующего штрихового кода информация о предыдущем сканировании сразу сохраняется в журнал, и количество сканирований не увеличивается, даже если сканируется тот же товар с тем же весом.
    В процессе сканирования производится сравнение подсчитанного количества товара и заказанного количества. Если подсчитанное количество превышает заказанное с учетом разрешенного отклонения от заказанного количества, то выдается предупреждение и регистрация не разрешается. Разрешенное превышение берется из контракта с поставщиком, действующего на дату приема товара.
  • Количество в упаковке – количество товара в упаковке, соответствующей штриховому коду. Для весового товара это количество берется из штрихового кода этикетки.
  • Количество – произведение количества сканирований на количество в упаковке, то есть количество товара в текущей сессии сканирований.
  • Срок годности – поле для ввода значения срока годности товара.
  • Всего количество посчитанное – общее количество данного товара (артикула), посчитанное в ходе сверки, включая подсчеты с иными штриховыми кодами данного артикула.
  • Заказ – количество заказанного товара.
  • Максимальная цена – максимально возможная цена поставки. Определяется ценой и предельным отклонением цены из контракта с поставщиком.
    Закладка «Журнал».


    На закладке показывается история сканирований с расположением записей в порядке, обратном хронологии. То есть, самое последнее сканирование показывается в первой записи таблицы. Журнал можно редактировать. При ошибочном сканировании можно удалить запись из журнала или скорректировать количество сканирований. Для весового товара количество сканирований изменить нельзя.
    В нижней части страницы отображается детальная информация по выбранной строке таблицы: название артикула и его общее посчитанное количество.
    Закладка «Спецификация».


    На закладке показывается список всех артикулов из заказа поставщику. Записи отсортированы в алфавитном порядке названия артикула. В таблице показывается количество заказанного товара «Заказ», подсчитанное количество «КолФ», количество не поставленного товара «НеПост», количество ранее поставленного товара по данному заказу «УжеПост» и количество допустимого превышения количества заказа «Пред» по действующему контракту с поставщиком.
    Если количество принятого товара с учетом ранее принятого, превышает заказ, число в поле «НеПост» выводится красным цветом, даже если по контракту можно принять больше, чем заказано.
    Строки спецификации окрашиваются зеленым фоном, если количество принятого товара равно количеству заказа и желтым, если превышает количество заказанного в пределах разрешенного превышения.
    Закладка «Завершение».


    На закладке показывается содержание задания приема товара на основании заказа и кнопка завершения работы. При нажатии на кнопку «Завершить прием» фиксируется время окончания работы и блокируется возможность дальнейшего подсчета товаров. Далее можно передать данные на сервер, приступить к новому приему на основании заказа или выйти из программы. При переходе к другому заданию по приему товаров или выходе из программы до передачи данных на сервер, накопленные данные будут сохранены с возможностью передать их в другое время, например, если беспроводное соединение в данном месте здания не доступно.
    После успешной передачи данных их можно удалить и приступить к следующей работе.
    В случае, когда накоплены данные о приеме нескольких поставок, для передачи данных о них на сервер необходимо выбрать завершенные приемы на экране «Прием товаров по заказу» и нажать кнопку «Выбор». Далее в окне «Прием товара по заказу передать» выбрать опцию «Отослать и удалить выбранные процессы приема товаров» и нажать кнопку «ОК». Удаление данных после успешной передачи сопровождается диалогом подтверждения.

    Контроль ценников.


    Перед началом работы по контролю цен в ценниках торгового зала программе ТСД необходимо получить информацию об артикулах и их ценах. Список товаров может определяться по группам классификатора товаров, по номенклатурам, по зонам инвентаризации действующей планограммы торгового зала или по элементам (стеллажам, холодильным ларям и т.д.) планограммы.
    В ходе работы информация об артикуле, не входящем в первоначальный список, может быть получена по беспроводному соединению, тем не менее, вариант работы без предварительной загрузки артикулов не предусмотрен, поскольку предварительная загрузка значительно уменьшает время реакции на сканирование штрихового кода и снижает риск перерывов в работе при неустойчивой работе беспроводного соединения.
    Варианты выбора списка артикулов следующие:






    В соответствии с выбранным вариантом выбора списка товаров программа ТСД запрашивает с сервера данные классификатора групп товаров, номенклатур или планограммы.
    Далее необходимо сформировать задание путем выбора необходимого перечня групп классификатора товара, номенклатур, зон инвентаризации или элементов планограммы.
    После подтверждения выбора программа запрашивает с сервера данные об артикулах товаров, входящих в состав задания: артикулы, название, штриховые коды, цены.


    Закладка «Контроль».
    Закладка для сканирования или ручного ввода штрихового кода товара. Если сканирование штрихового кода происходит при нахождении на другой закладке рабочего режима, автоматически будет осуществлен переход на закладку «Контроль» и предоставлена информация о сканируемом товаре.
    На закладке показывается количество в упаковке, цена товара, выпадающий список типов ценников для артикула и кнопка «Новый ценник».
    При нажатии на кнопку «Новый ценник» артикул заносится в журнал с выбранным типом ценника, формируя список ценников, требующих печати.
    Если требуется обновить несколько категорий ценников, надо выбрать требуемую категорию ценника и еще раз нажать кнопку «Новый ценник».




Закладка «Журнал».


На закладке показывается история занесения в журнал артикулов и типов ценников, требующих новой печати.


Если категория ценника была указана не верно, в журнале можно ее поправить, либо удалить запись и просканировать ценник заново.

Закладка «Завершение».




На закладке показывается содержание задания и кнопка завершения работы. При нажатии на кнопку «Завершить» фиксируется время окончания работы и блокируется возможность дальнейшего контроля цен в ценниках. Далее можно только передать данные на сервер или выйти из программы. При выходе из программы до передачи данных на сервер, накопленные данные будут сохранены с возможностью передать их в другое время, например, если беспроводное соединение в данном месте здания не доступно.
После успешной передачи данных их можно удалить и приступить к следующей работе.
Печать ценников по списку, полученному в ходе выполнения задания, осуществляется в экземпляре процесса «Контроль ценников ТСД», который создается в процессе передачи данных задания на сервер.

Принтеры этикеток. Формат файла описания этикеток.


Содержание файла описания этикеток зависит от типа принтера и состоит из команд языка принтера этикеток и ключевых слов торговой системы. При печати этикетки Торговая система производит замену ключевых слов на соответствующие им данные.
Список ключевых слов:
%ARTICUL – Артикул карточки складского учета
%NAME – Название карточки В зависимости от настройки Торговой системы в данное поле помещается название товара или короткое название товара (если короткое название в карточке не задано, то полное название). При печати из пункта меню «Печать этикеток упаковок» в поле %NAME помещается название упаковки и количество в упаковке

%NAME1 – вторая часть названия Алгоритм заполнения см. ниже.
%NAME2 – третья часть названия Алгоритм заполнения см. ниже.

%SIZE - индивидуальные свойства (размер, цвет, сорт и т.д.) Только для артикулов типа «Признак»

%BARCODE - штриховой код (EAN/UPC)
%BARPRICE - штриховой код c ценой и кодом вида ценника С версии 1.039. Формат кода PR|<BarCode>|<Price*100>|<PricerCategory>
%QUANTITY - количество товара в упаковке Поле %QUANTITY сохранено для совместимости с v2.6. Для новых этикеток следует использовать поле %PACKSIZE

%PRICERUB - цена в основной валюте
%PRICECUR - цена во вспомогательной валюте
%OLDPRICE - старая (предыдущая) цена в основной валюте
%COPIES - количество копий этикеток Количество копий этикеток указывается в диалоге печати этикеток и в случае, если данного ключевого слова не обнаружено, то этикетка посылается на принтер указанное количество раз, в случае обнаружения данного ключевого слова в это место проставляется число копий, а этикетка посылается на печать один раз

%COUNTRY - название страны При печати этикетки из раздела карточек складского учета страна берется из карточки, при печати из документа, страна берется из строки спецификации документа

%CLIENT - название контрагента Только при печати по спецификации документа

%DOCDATE - дата документа При печати из разделов документов – дата документа, при печати из раздела карточек – текущая дата (дата печати)
%COMMENT - комментарий карточки
%PACKSIZE - количество товара в упаковке
В случае печати этикетки на единицу товара в данное поле помещается 1

%VALIDDATE - дата истечения годности Только при печати по спецификации документа

%BARDATE - штриховой код с датой истечения годности товара (CODE128) Только при печати по спецификации документа

%MEASURE – полное название единицы измерения для отчетов Название единицы измерения берется из карточки товара из поля Полное название единицы измерения для отчетов.

%DESCRNN_XXXXXX – значение дополнительной характеристики Где NN – номер строки дополнительной характеристики, например, 1. Если NN не задано, то выводится первая строка дополнительной характеристики. XXXXX – идентификатор дополнительной характеристики, например, Sys.BrandName – торговая марка. Идентификатор не должен иметь пробелов.

%GROUPNAME - название группы классификатора товаров
%GROUPNUM - номер группы классификатора товаров (позиция в дереве)
%PRICERINT - цена в основной валюте целая часть (рубли) С версии 1.031.2.
%PRICERFRACT - цена в основной валюте дробная часть (копейки) 16
%PRICECINT - цена во вспомогательной валюте целая часть16
%PRICECFRACT - цена во вспомогательной валюте дробная часть16
%PRINTDATE – дата печати в формате ДД.ММ.ГГ С версии 1.040. сп1
%PRINTTIME – время печати в формате ЧЧ:ММ:СС17
%MANUFACTURER – производитель по умолчанию из карточки складского учета17
Торговая система поддерживает одновременное использование двух файлов форматов этикеток – для нужд учета и касс и для нужд склада, то есть для использования составного штрихового кода, который идентифицирует товар и дату истечения годности товара. Оба файла должны быть рассчитаны на один и тот же размер этикетки.
Если принтер этикеток требует фиксированную длину поля, то после ключевого слова можно указать размер поля, например, %NAME=20. Если фактическая длина поля меньше, то оно дополняется пробелами справа, если больше, то обрезается.
Поля %NAME1 и %NAME2 заполняются частями названия карточки, Заполнение происходит в случае, если для этих полей и для поля %NAME указано ограничение длины и длина названия карточки превысило это ограничение. Перенос осуществляется по словам за исключением последней части, которая ограничивается длиной поля. Если длина поля такова, что ни одно слово не помещается целиком, то слово переносится по символу.
Поле %COPIES по умолчанию имеет длину четыре символа и дополняется нулями слева, например, «0002». Можно указать требуемый размер, например, %COPIES=6 – «000002». Для того чтобы не печатать лидирующие нули, нужно указать %COPIES=0.
Поддерживаются две кодировки русских букв при выводе значений полей: DOS и Windows.
Этикетка может содержать также следующие специальные символы:
«\a»- Bell (alert) – символ с кодом 07h
«\b»- Backspace – символ с кодом 08h
«\f»- Formfeed – символ с кодом 0Ch
«\n»- New line – символ с кодом 0Ah
«\r»-Carriage return – символ с кодом 0Dh
«\xFA- символ с указанным шестнадцатеричным кодом (в примере 250=FAh)
«\50»- символ с указанным восьмеричным кодом (в примере 40=50oct=28h)
Для вывода символа обратной косой черты «\», его следует написать два раза: «
», например, «
a» выведет текст «\a», «\a», выведет один символ с кодом 7.

  • Нет меток