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

Общая схема представления данных.

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

 Контроль отгрузок.

Система АУБ – Контроль отгрузок — это программно-аппаратный комплекс, в котором взаимодействие с весами осуществляется посредством специализированного контроллера, все данные хранятся на сервере и не связанны с компьютером весовщика. Таким образом, у Вас не будет ситуации, когда весовщик допустит проезд автотранспорта без взвешивания просто выключив программу. Все показания весов хранятся внутри системы вне зависимости от присутствия весовщика и могут быть легко проанализированы. Кроме того, в системе могут фиксироваться все взаимодействия весовщика с периферийным оборудованием таким как сканеры штрих-кодов и R-FID. 

Такой подход позволяет не только фиксировать все действия весовщика, но и полностью автоматизировать процессы:

• повторное взвешивание клиентов;
• взвешивание технологического транспорта.

Благодаря этому удается увеличить пропускную способность весовой.

С внедрением нашей программы для автоматизации весовых на Карьере Борок в г. Новосибирске количество отгрузок в сутки доходило до 1000 машин клиентов и 200 рейсов  технологического транспорта.

 Каналы связи, масштабируемость, безопасность.

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

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

 Учет каждого автомобиля.

Система АУБ – Контроль отгрузок осуществляет учет каждого автомобиля клиента. Позволяя анализировать следующие параметры

• На какой точке отгрузки побывал автомобиль. От имени какого клиента\перевозчика.
• Какие водители были.
• Во сколько заехал, во сколько взвешался пустой, полный, во сколько получил документы, во сколько выехал.
• Какие показания были на весах.

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

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

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

 

Схема документооборота.

    Схема показывает каким образом происходит документооборот в подстсеме АУБ. Как вы видите большинство связей не обязательны, благодаря этому существует множество вариантов использования. Опишем наиболее используемые, это поможет понять возможности системы.

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

 Вариант 2. Более сложным вариантом является, вынос части функциональности в отдельную подсистему. Для нашего примера документы "Реализация МТР" создаются не просто на основании заказов, а автоматически используя подсистему АУБ - Автоматизация отгрузок. При этом всегда можно определить какой из документов "Реализация МТР" был создан на основании каких отгрузок и если есть необходимость, произвести автоматическую сверку.  Отдельная подсистема нужна из следующих соображений. 1. Безопастность. В случае если база будет передана 3-м лицам, то в ней просто не окажется лишних данных. 2. Доверие. На удаленной точке работают люди, уровень доверия к которым низкий и поэтому знать лишнюю информацию им не нужно. 3. Стоимость оборудования. На удаленной точке отгрузки можно не иметь дорого оборудования и каналов связи. 4. В случае форс-мажерных обстоятельств нет необходимости имитировать все события отгрузки. Достаточно  внести данные на уровне реализаций. И это будет видно, объяснимо, и что самое главное правдиво.

 Вариант 2.1. Основной для отгрузки инертных. Из заказов формируем документы "Лимит", который является по сути разрешением на отгрузку. И это является правильным, т.к. утверждение заказа не означает, что  ТМЦ может быть отгружено, в силу различных обстоятельств. Из лимитов формируются идентификаторы. Идентификаторы могут быть 2-х типов разовые и многоразовые. Разовые могут использоваться только 1 раз и все, многоразовые несколько раз. Разовые удобно использовать клиентам которые хотят ограничить водителей в количестве рейсов, например в случае наемного транспорта. Так клиент может выделить водителю определенной машины 3 разовых идентификатора, и это означает что этот водитель сможет получить (в рамках ограничений по лимитам) ТМЦ только 3 раза (рейса). Идентификаторы могут быть записаны на разные носители: бумага (штрих-код) или RFID карта (NFC). На идентификатор может накладываться дополнительное ограничение, например номер транспортного средства, номенклатура, период действия и т.д. Таким образом достигается дополнительная гибкость.  

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

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

 Вариант 2.2. Основной для отгрузки бетонов с доставкой.  Диспетчер анализирует заявки на отгрузку на следующий день, и заказывает нужные для доставки миксеры. На следующий день миксеры приезжают в назначенное время на точку погрузки, весовщик вводит их в контур и взвешивает пустыми. Диспетчер видя перечень заявок и миксеров готовых к отправке формирует документ "Отгрузка", в котором автоматически, в зависимости от типа миксера и установленных по заявке цен, формируется цена доставки, и стоимость бетона , распечатывается погрузочный талон, с которым миксер отправляется на загрузку.  После загрузки миксер повторно взвешивается весовщиком и ему выдаются необходимые документы. При этом существует возможность контролировать отклонение между плановым объемом загрузки и фактическим и выводить в документах для клиента либо тот, либо иной,  а в случае превышения заданной величины отклонения, будет выдано предупреждение. Например: норма 5м3, а загружено по факту 4,9м3 отклонение будет около 50 кг/м3, при разрешенном отклонении, предположим, 80 кг/м3 документ будет проведен без предупреждения и в документе будет стоять объем 5м3, но если отклонение будет больше допустимого, то диспетчеру нужно будет выбрать что сделать, либо указывать в документе фактический объем, либо указать норму. Кроме того, информацию по норме и факту видит мастер РБУ, который либо меняет плотность у номенклатуры,  либо вводит поправочный коэффициент для класса номенклатур, либо совершает иные действия. 

Вариант 3. Розница. Похож на вариант 2.1. только идентификатор на погрузку выдает сотрудник охраны, а не менеджер. Кроме того в документе отгрузка предусмотрен ввод  поступивших от клиента денег, причем деньги могут поступать как сразу так и после доставки клиенту, если доставка осуществляется нашими перевозчиками. Таким образом мы всегда знаем, какие долги за товар/доставку по какой отгрузке есть, и если это доставка знаем транспортное средство и водителя который не внес деньги в кассу.

Все перечисленные выше варианты не взаимоисключающие и  могут существовать на одном предприятии одновременно, даже в рамках одной точки доставки. Кроме того, в системе существует возможность контролировать поступающие ТМЦ, а так-же перемещения как внутри одной точки погрузки, так и между разными. Если точки погрузки и выгрузки разные, то сопоставление между тем какое количество ТМЦ было на точке погрузки, а сколько стало при выгрузке происходит автоматически (так называемый биективный контроль). И это далеко не весь перечень возможностей нашей автоматизации!

Варианты контроля количества отгрузок.

В подсистеме присутствуют многообразные варианты контроля над объемом отгрузок и способами оплат и ценами доставки.

Может быть

Розничный самовывоз

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

 Различные варианты мелкого и крупного опта

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

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

Опт

Их тоже несколько вариантов.

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

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

Кроме того ограничить можно не только объем продукции. Но и количество ездок.

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

 Контроль спецтехники

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

Идентификация.

Клиента можно идентифицировать 3 способами

1. Дать клиенту несколько разрешений на разовую отгрузку. Одно разрешение на одну погрузку. При этом различные виды ограничений описанных выше остаются (рубли\тонны с достакой и т.п.)
2. Дать ему несколько пропусков на погрузки.  При этом на каждое разрешение устанавливается срок и объем, а рейсы не ограничиваются. При этом срок для каждого разрешения может быть свой.
3. Идентификация по транспортному средству. При этом клиенту ничего не выдается, а в систему вводится номера машин, которым можно загружаться.

 

Можно установить модуль «АУБ – контроль взаимоотношений» и там есть CRM учет цен, заказов, перенос в типовую учетную систему и множество других полезных функций.

Про концепцию АУБ можно прочитать в разделе Концепция автоматизации многопрофильного Холдинга в системе АУБ на платформе 1С