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

14.10.19

Задачи пользователя - Адаптация типовых решений

+3 –
> > > >
  • 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. Контроль своевременности передачи заявки в набор и контроль даты отгрузки заявки покупателя
 

+3 –

См. также

Улучшенная обработка "Внешние печатные формы" для типовых конфигураций на базе 1С 7.7

Печатные формы Адаптация типовых решений Программист Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Приятное улучшение обработки "Внешние печатные формы" для типовых конфигураций на базе 1С 7.7 для более комфортной работы с "любимой семерочкой".

1 стартмани

04.02.2022    3349    1    igor7777    0    

3
Расчет страховых взносов в 1С 7.7 "Учет и отчетность предпринимателя, ред. 1.2" с апреля 2020

Адаптация типовых решений Программист Платформа 1С v7.7 Конфигурации 1cv7 Россия Бухгалтерский учет ФОМС, ЕФС Бесплатно (free)

В этой статье описано, какие небольшие изменения можно внести в модуль документа Начисление налогов с ФОТ, чтобы правильно рассчитывались страховые взносы с 1 апреля 2020 г.

09.04.2020    20633    Юджин58    39    

5
Дистрибьюция 7.7. Часть 3. Задание на набор и контроль выполнения набора товара для отгрузки

Монитор заказов Оптовая торговля Программист Пользователь Оперативный учет 7.7 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Управленческий учет Абонемент ($m)

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

1 стартмани

16.10.2019    10422    1    ksnik    3    

3
Дистрибьюция 7.7. Часть 2. Контроль выполнения заявки покупателя по номенклатуре

Оптовая торговля Монитор заказов Программист Пользователь Оперативный учет 7.7 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Управленческий учет Абонемент ($m)

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

1 стартмани

15.10.2019    10982    1    ksnik    0    

4
Раздел 9 декларации по НДС за 1 квартал 2019

Адаптация типовых решений Оптовая торговля Производство готовой продукции (работ, услуг) Программист Бухгалтерский учет 7.7 1С:Комплексная 7.7 Россия Бухгалтерский учет Налоговый учет НДС Бесплатно (free)

Ошибка при формировании Раздела 9 декларации по НДС в 1С к.к. 7.70.577.

12.04.2019    8394    eroma    12    

1
Как в торговле 7.7 печатать код ТНВЭД в счет-фактуре

Операции по ВЭД Адаптация типовых решений Программист Оперативный учет 7.7 1С:Торговля и склад 7.7 Россия Бухгалтерский учет НДС Бесплатно (free)

В данной статье хотел поделиться опытом, как в Торговле 7.7 ( релиз 994) сделать возможность выводить код ТНВЭД в печатную форму счета-фактуры. Сразу скажу, что нужно это только тем, кто осуществляет экспорт в страны таможенного союза. Остальные могут не волноваться.

15.11.2017    12034    AndKovalchuk    0    

1
Доначисление страховых взносов на обязательное страхование от НС и ПЗ в Бухгалтерии 7.7 и УСН 7.7 для Договора подряда

Зарплата Адаптация типовых решений Программист Бухгалтерский учет 7.7 1С:Бухгалтерия 7.7 1С:Упрощенное налогообложение 7.7 Россия Бухгалтерский учет ФОМС, ЕФС Бесплатно (free)

Во всех источниках, которые мне встречались, написано, что Страховые взносы НС и ПФ нужно начислять, если это указано в Договоре подряда.

06.09.2017    11135    pentanom    0    

3
Пилотный проект ФСС. Заявление, реестр, опись, выгрузка в формате xml версия 1.7.2.

Работа с интерфейсом Зарплата Адаптация типовых решений Программист Бухгалтер Расчет 7.7 1С:Зарплата и кадры 7.7 Россия ФОМС, ЕФС Абонемент ($m)

Типовые объекты конфигурации не изменены, поэтому подходит для любого релиза ЗиК.

1 стартмани

29.07.2016    16959    21    Cvetic    1    

2
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. CheBurator 2712 14.10.19 12:32 Сейчас в теме
"на каждую точку основного покупателя одну колонку, всего до 40 дополнительных колонок количества. "
- фу, какая бяка страшная. появился 41 точка - надо весь код "рефакторить".

Остальное по тексту - уже не столь существенное, сделать можно по разному, как сделано в конкретной реализации - на вкус и цвет.
+ – Ответить
2. ksnik 593 14.10.19 12:41 Сейчас в теме
(1) Нежно иметь ввиду, что количество колонок это не количество точек у покупателя всего, а сколько должны быть привезены одновременно в одну дату доставки. Заранее известно сколько точек максимально мы можем отвезти за один раз. Работа с основным покупателем как правило статична. А вообще можно хранить количество точек заявки в глобальной переменной, чтобы позже проще было модифицировать код. Тогда если потребуется увеличить максимальное количество точек заявки, можно увеличить значение глобальной переменной, и переписывать код не нужно.А вот реквизит табличной части программно не добавишь. На 40 точках оно работает без проблем. До 40 раз сокращает документооборот. А как будет при большем количестве точек я не знаю, как будет работать - не пробовал.

В ответ на замечание, что можно реализовать данный функционал как угодно - я не согласен, от архитектурного решения далее сильно зависит программная реализация, а решение может внезапно оказаться и тупиковым - поэтому готовые опробованные на чьем-то опыте и рабочие решения принимать к сведению всегда имеет очень большой смысл.
acanta; +1 – Ответить
4. CheBurator 2712 14.10.19 13:29 Сейчас в теме
(2) количество колонок в документе визуально может быть как посчитаете нужным. а вот делать это статичными реквизитами самого документа - бяка. именно про это.
.
"реализовать данный.." - это не про 40 колонок, а общую схему работы, отражаемую в базе. я бы - делал несколько иначе. но это как раз - несущественно - на вкус и цвет.
.
как пример, информационно, - у меня нет задачи постоянного обеспечения "точек" клиента. но например есть такая сеть как "Фамилия", где присылается от клиента общий заказ (и отгружается по документам общий заказ), а по сути формируется до (у нас) 280 отдельных заказов по точкам. Это все реализовано без дополнительных документов, на базе только заявок клиентов.
+ – Ответить
5. CheBurator 2712 14.10.19 13:33 Сейчас в теме
(4) понятно, что сделано - то сделано.
как пример в концепции - вот есть у меня документ "универсальный двигатель регистров". он работает под любой регистр. так и в контексте обсуждения - ну будет не 40 одновременно, а 30. или 50 - и переделывать. при этом можно было сделать решение что и на 40 без перепрограммирования\изменения конфигурации, и под 30 и под 50 будет работать.
.
хотя, надо честно сказать что аналогичные костыли и у меня есть, бо сделано было когда-то, работает ну и работает, раз в полгода год тратится полчаса времени, чтобы по просьбе менеджеров "скорректировать костыль".
+ – Ответить
6. ksnik 593 14.10.19 14:09 Сейчас в теме
(4)
280 отдельных заказов по точкам

при желании минимизировать документооборот (ведь каждый документ стоит денег) Вы тоже можете переделать на лад "Как в Экселе". Одну реализацию провести проще, чем 280 реализаций, а суть одна. Но в данном случае в публикации я акцентировал, что достигаю ситуации - либо отгружено всё и нет штрафных санкций, либо ничего. Это дисциплинирует персонал дилера. Обещаем привезти заявку - собираем всю целиком. Затем беремся за следующую. Это дисциплина и порядок. Не справляемся - не обещаем что привезем, бо всё прозрачно видим. А если хаос из большого количества реализаций, то сложнее контролировать выполнение.
+ – Ответить
9. CheBurator 2712 15.10.19 00:14 Сейчас в теме
(6) это все понятно.
у меня, в приведенном примере, реализация - одна, менеджер проводит одну реализацию.
но внутри в отгружаемом со склада массиве товара - отдельно маркированнные 280 "подзаказов". каждая точка собирается и маркируется (спецупаковочный литст по формату покупателя с кучей логистики покупателя) отдельно.
+ – Ответить
10. ksnik 593 15.10.19 06:51 Сейчас в теме
(9) Таоой функционал у нас в 77 не реализован так как сетка таблицы нагляднее. Закупка собственной розницы в 83 (обычные формы) тоже предпочитает работать с сеткой, проверять и исправлять несколько магазинов со сходными параметрами совокупно. Дело в том, что проверка заказа на каждую точку (не в сетке) - это просто нереальный труд. Даже если из отчета через расшифровку открывать документ и как-то автоматически позиционироваться в нем на нужную позицию для исправления, все равно черезчур будет подвисать (в 7ке если транзакция и открываются документы медленнее) и мельтишить от смены на экране кучи форм. Дла розницы сетка это всё. А я анонсировал в публикации вариант как сделать систему дистрибьютора продолжением розничной системы, сблизить поставщика с покупателем.

Но в 1С8 есть подобный описанному Вами функционал (разбитие общей заявки на отдельные заявки по магазинам) который востребован на складе, если магазинов в заявке много каждый наборщик может брать по одному магазину в руки, даже по складу можно ходить толпой.
+ – Ответить
12. CheBurator 2712 15.10.19 13:35 Сейчас в теме
(10) конечно, с шахматкой-сеткой работать удобнее. в некоторых рабочих процессах такое у меня представлено. у меня не стоит выверка на входном потоке правильности заявок (так что тут легче у меня).
+ – Ответить
11. ksnik 593 15.10.19 08:58 Сейчас в теме
(9)
у меня, в приведенном примере, реализация - одна, менеджер проводит одну реализацию.
но внутри в отгружаемом со склада массиве товара - отдельно маркированнные 280 "подзаказов"

Я бы с большим интересом посмотрел на код который списывает резервы и поддерживает актуальные остатки от момента набора первой заявки до формирования реализации. Мой вариант - почти без доработок типовой конфигурации.
+ – Ответить
13. CheBurator 2712 15.10.19 13:46 Сейчас в теме
(11) а чего тут смотреть? если в учете порядок - то вообще никаких проблем. зарезаервировал товар штатно (у меня тис), задания на сборку (бумагу или ТСД - у меня так было долгое время) - и пошел собирать. Никакого "поддержания актуальных остатков" - вообще речи не идет. Остатки всегда актуальны, все работают только в ТА, никаких оперативных задач задним числом не выполняется. А когда синтегрировал ТИС в полноценной WMS - тоже принципиально ничего не поменялось. конечно, когда за недовоз 1шт товара из 700шт - бешеные штрафы и при этом остатки на складе колеблются с учетом активных заявок возле нуля - то здесь для поддержания актуальных остатков должна быть высокая складская дисциплина и спецрегламенты процессов склада. Тоже ничего особого, все обеспечивается постоянной упорной работой, контролем и люлями. у вас примерно так же, более чем уверен ;-)

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

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

Всем успехов!
+ – Ответить
14. ksnik 593 15.10.19 14:21 Сейчас в теме
(11) на мой взгляд первая заявка набралась = надо снять резерв и провести частичную реализацию, вторая набралась - надо снять резерв и провести совокупную реализацию на две заявки, и так перепроводить реализацию 280 раз. А иначе никто не узнает, что собрано а что нет и возникнет бардак. А если резерв снять а остатки не реализовать сразу, тогда освободившийся товар кто-то умыкнет в новую заявку, и возникнет ошибка...
+ – Ответить
3. acanta 14.10.19 13:01 Сейчас в теме
Сделайте как в екселе (с)
JohnyDeath; ksnik; +2 – Ответить
7. acanta 14.10.19 14:18 Сейчас в теме
К этому хозяйству ещё итоговый отчёт должно быть, за месяц-год, учитывающий что количество и состав (нумерация) складов клиента меняется в течение этого времени.
Регистр оборотный сюда хорошо вписывается.
+ – Ответить
8. ksnik 593 14.10.19 14:35 Сейчас в теме
(7) Все верно Вы правы, я уже и забыл что регистр "ВыполнениеЗаявок" не типовой. Еще момент - в этом регистре у меня не хватает измерения "Склад", пришлось из-за этого много потрудиться над отчетом когда возникла необходимость исключить из отчета транзитный склад.
Прикрепленные файлы:
acanta; +1 – Ответить
Оставьте свое сообщение