Дистрибьюция 7.7. Часть 1. Жизненный цикл заявки покупателя. Одна заявка покупателя, много адресов доставки.

14.10.2019 14 Comments

Практика программирования, Разработка





    z1.png
    z2.png
    z3.png
    s2.png
    s3.png

Описан способ работы с учетом расписания с приоритетными покупателями — торговыми сетями (основными покупателями) в торговой или комплексной учетной системе на 1С 7.7. Множественная заявка покупателя на несколько торговых точек.

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

1. Реализуем единую заявку на несколько торговых точек.

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

В модуле документа или формы эти колонки можно обработать например так (на примере округления до упаковок):

Для Сч = 1 По 40 Цикл
ТекКоличество = ПолучитьАтрибут("Склад" + Сч);
Если ТекКоличество % КоэффициентУпаковки <> 0 Тогда
УстановитьАтрибут("Склад" + Сч, (Цел(ТекКоличество / КоэффициентУпаковки) + 1) * КоэффициентУпаковки);
КонецЕсли;
КонецЦикла;

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

При работе с торговыми сетями особое значение имеет в составе конфигурации справочник торговых точек — физических адресов прилавков (мест ведения торговли) нашего драгоценного основного покупателя. Один сетевой клиент имеет более одной торговой точки. Справочник торговых точек подчинен справочнику контрагентов.

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

Шапка табличной части заполняется следующим образом:

 

 Пример заполнения наименований колонок табличной части заявки покупателя

Разобрав таким образом строку складов можно для каждого склада получить фактический адрес доставки.

 

 Пример сопоставления кодов из строки складов фактическим адресам доставки

Заявки покупателя не обязательно должны быть множественными (на несколько точек сразу). Чтобы предусмотреть возможность закрепления единственного фактического адреса доставки в одну заявку, добавим в шапку заявки реквизит "ТорговаяТочка" связанный со справочником фактических адресов доставки, подчиненных контрагентам.

2. Реализуем выполнение заявки по точкам и контроль выполнения заявки.

Чтобы стать продолжением нашего покупателя (который всегда прав) и четко выполнять его заявки, доработаем нащу учетную систему механизмом контроля выполнения заявки по точкам. Скопируем заявку покупателя, получится документ ЗаявкаПокупателяКопия. Назовем её в синониме объекта метаданных как "Заявка (остатки)".

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

 

 Пример реализации программного копирования заявки в описанную выше заявку-копию

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

 

 Пример обрезки заявки покупателя по остаткам

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

Таким образом мы имеем первичную потребность покупателя в документе "ЗаявкаПокупателяКопия" или Заявка (Остатки) и можем сравнить первичную заявку — то, что просил основной покупатель с тем, что было у нас в учете, сохраненным в документе "ЗаявкаПокупателяКопия1" или Заявка (Склад). Так же мы можем сравнить фактически набранную заявку покупателя, это основной документ "ЗаявкаПокупателя" с заданием на набор, то есть с документом "ЗаявкаПокупателяКопия1" или Заявка (Склад).

Структура данных показана на примере комплексной конфигурации 4.2 (7.70.424). Версия платформы 7.70.027.

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

 

Часть 2. Контроль выполнения заявки покупателя по номенклатуре

Часть 3. Контроль своевременности передачи заявки в набор и контроль даты отгрузки заявки покупателя
 

Related Posts

14 Comments

  1. CheBurator

    «на каждую точку основного покупателя одну колонку, всего до 40 дополнительных колонок количества. »

    — фу, какая бяка страшная. появился 41 точка — надо весь код «рефакторить».

    Остальное по тексту — уже не столь существенное, сделать можно по разному, как сделано в конкретной реализации — на вкус и цвет.

    Reply ↓
  2. ksnik

    (1) Нежно иметь ввиду, что количество колонок это не количество точек у покупателя всего, а сколько должны быть привезены одновременно в одну дату доставки. Заранее известно сколько точек максимально мы можем отвезти за один раз. Работа с основным покупателем как правило статична. А вообще можно хранить количество точек заявки в глобальной переменной, чтобы позже проще было модифицировать код. Тогда если потребуется увеличить максимальное количество точек заявки, можно увеличить значение глобальной переменной, и переписывать код не нужно.А вот реквизит табличной части программно не добавишь. На 40 точках оно работает без проблем. До 40 раз сокращает документооборот. А как будет при большем количестве точек я не знаю, как будет работать — не пробовал.

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

    Reply ↓
  3. acanta

    Сделайте как в екселе (с)

    Reply ↓
  4. CheBurator

    (2) количество колонок в документе визуально может быть как посчитаете нужным. а вот делать это статичными реквизитами самого документа — бяка. именно про это.

    .

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

    .

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

    Reply ↓
  5. CheBurator

    (4) понятно, что сделано — то сделано.

    как пример в концепции — вот есть у меня документ «универсальный двигатель регистров». он работает под любой регистр. так и в контексте обсуждения — ну будет не 40 одновременно, а 30. или 50 — и переделывать. при этом можно было сделать решение что и на 40 без перепрограммированияизменения конфигурации, и под 30 и под 50 будет работать.

    .

    хотя, надо честно сказать что аналогичные костыли и у меня есть, бо сделано было когда-то, работает ну и работает, раз в полгода год тратится полчаса времени, чтобы по просьбе менеджеров «скорректировать костыль».

    Reply ↓
  6. ksnik

    (4)

    280 отдельных заказов по точкам

    при желании минимизировать документооборот (ведь каждый документ стоит денег) Вы тоже можете переделать на лад «Как в Экселе». Одну реализацию провести проще, чем 280 реализаций, а суть одна. Но в данном случае в публикации я акцентировал, что достигаю ситуации — либо отгружено всё и нет штрафных санкций, либо ничего. Это дисциплинирует персонал дилера. Обещаем привезти заявку — собираем всю целиком. Затем беремся за следующую. Это дисциплина и порядок. Не справляемся — не обещаем что привезем, бо всё прозрачно видим. А если хаос из большого количества реализаций, то сложнее контролировать выполнение.

    Reply ↓
  7. acanta

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

    Регистр оборотный сюда хорошо вписывается.

    Reply ↓
  8. ksnik

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

    Reply ↓
  9. CheBurator

    (6) это все понятно.

    у меня, в приведенном примере, реализация — одна, менеджер проводит одну реализацию.

    но внутри в отгружаемом со склада массиве товара — отдельно маркированнные 280 «подзаказов». каждая точка собирается и маркируется (спецупаковочный литст по формату покупателя с кучей логистики покупателя) отдельно.

    Reply ↓
  10. ksnik

    (9) Таоой функционал у нас в 77 не реализован так как сетка таблицы нагляднее. Закупка собственной розницы в 83 (обычные формы) тоже предпочитает работать с сеткой, проверять и исправлять несколько магазинов со сходными параметрами совокупно. Дело в том, что проверка заказа на каждую точку (не в сетке) — это просто нереальный труд. Даже если из отчета через расшифровку открывать документ и как-то автоматически позиционироваться в нем на нужную позицию для исправления, все равно черезчур будет подвисать (в 7ке если транзакция и открываются документы медленнее) и мельтишить от смены на экране кучи форм. Дла розницы сетка это всё. А я анонсировал в публикации вариант как сделать систему дистрибьютора продолжением розничной системы, сблизить поставщика с покупателем.

    Но в 1С8 есть подобный описанному Вами функционал (разбитие общей заявки на отдельные заявки по магазинам) который востребован на складе, если магазинов в заявке много каждый наборщик может брать по одному магазину в руки, даже по складу можно ходить толпой.

    Reply ↓
  11. ksnik

    (9)

    у меня, в приведенном примере, реализация — одна, менеджер проводит одну реализацию.

    но внутри в отгружаемом со склада массиве товара — отдельно маркированнные 280 «подзаказов»

    Я бы с большим интересом посмотрел на код который списывает резервы и поддерживает актуальные остатки от момента набора первой заявки до формирования реализации. Мой вариант — почти без доработок типовой конфигурации.

    Reply ↓
  12. CheBurator

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

    Reply ↓
  13. CheBurator

    (11) а чего тут смотреть? если в учете порядок — то вообще никаких проблем. зарезаервировал товар штатно (у меня тис), задания на сборку (бумагу или ТСД — у меня так было долгое время) — и пошел собирать. Никакого «поддержания актуальных остатков» — вообще речи не идет. Остатки всегда актуальны, все работают только в ТА, никаких оперативных задач задним числом не выполняется. А когда синтегрировал ТИС в полноценной WMS — тоже принципиально ничего не поменялось. конечно, когда за недовоз 1шт товара из 700шт — бешеные штрафы и при этом остатки на складе колеблются с учетом активных заявок возле нуля — то здесь для поддержания актуальных остатков должна быть высокая складская дисциплина и спецрегламенты процессов склада. Тоже ничего особого, все обеспечивается постоянной упорной работой, контролем и люлями. у вас примерно так же, более чем уверен 😉

    Прим: склад ничего самостоятельно не делает. только по ЦУ от учетной системы. Самостоятельно склад проводит только выбраковку и инвентаризации текущие. Для «поддержания актуальных остатков» отклонения (то что прошло по выбраковке и по инвентаризации — должны максимально быстро отражаться в учетной системе. и все.

    (я подумывал тоже расписать что как у меня делается, а потом — оно кому интересно будет? взять и с ходу применить — 99.99% не получится, потому что программные решениядоработки тесно связаны с организационно-административными действиями, регламентами и прочими. комплекс. сделать комплекс — вещь непростая. а описать кейс — это проще самому сделать 😉

    Всем успехов!

    Reply ↓
  14. ksnik

    (11) на мой взгляд первая заявка набралась = надо снять резерв и провести частичную реализацию, вторая набралась — надо снять резерв и провести совокупную реализацию на две заявки, и так перепроводить реализацию 280 раз. А иначе никто не узнает, что собрано а что нет и возникнет бардак. А если резерв снять а остатки не реализовать сразу, тогда освободившийся товар кто-то умыкнет в новую заявку, и возникнет ошибка…

    Reply ↓

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *