Форум казахстанского налогоплательщика

Alkor писал :

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

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

немного не понял цель данной ветки.

Ну, обсудить - это и цель данной ветки...В споре рождаются истины.

Прекрасно понял вашу концепцию "программы для программистов", спасибо. Заявки-материалы-визиты к заказчику-счета-оплата-расчет зарплаты программиста-контроль. Неплохо.

Наша особенность в том, что железо мы не продаем, "комплектухой" никакой не занимаемся - только услуги. ЗП программстов у нас также вычисляется давно и точно, в привязке к работам учет ЗП нам не нужен.
Важную роль в таком деле, ИМХО, играют взаимоотношения с клиентом. Прописные истины про вежливость общения с клиентом описывать не буду.
Суть в том, что клиенты наши в основном долгосрочные, долговременные. Работа ними идет годами, с разной степенью интенсивности. А случись что - и не видно, что у него было, как работали и т.д. За исключением, конечно, бухбазы со счетами/СФ/оплатой. Но бухдоки - весьма слабое отражение реальной, многозначной работы с клиентом.

Или пришел новый программист. Едет к новому (для него) клиенту. А и не знает ничего про клиента, к которому едет, разве что спросит у какого нибудь "ветерана". Никакой хронологии и истории взаимоотношений нигде не видно. Все в памяти "ветеранов" хранится, как в древние века, до изобретения письменности.
И это плохо. Это было первое, что я осознал.

аааа )))) Здесь у нас та же проблема, сейчас думаем как бы так хитро организовать отчет по выполненным работам т.е программист такой то был там то клиент обратился с такой то проблемой, были произведены следующие работы, даны следующие рекомендации (конкретней, думаем как вводить выделенное) у программистов возникает вопрос как понять какие работы были произведены? к примеру настройка того же модема, не прописывать же в конце концов всю процедуру настройки модема, потом возникает вопрос до какой степени все детализировать. Опять же если требовать все эти отчеты то когда работать? Да и потом когда программист объезжает за день по 5-6 клиентов он разве вспомнит что он делал с утра, а заполнять тот же самый отчет у клиента тоже проблематично, потому что уже следующий названивает и торопит с приездом. Да даже если и будет время заполнять отчет у клиента, то где он будет заполняться? на бумажке скорей всего, а кто этот отчет будет переводить в электронный вид менеджер или программист? у менеджера своей работы хватает, а программисты обычно загруженны по самые недерланды что по приезду в офис они занимаются другой работой. По сути дела эти отчеты добавляют очень много не нужной работы, которую будут выполнять не охотно, потому что ни менеджеру ни программисту это не надо. Это надо мне как руководителю и будующему поколению. Есть у меня друзья они к этому подошли таким образом: у них есть карта посещений, приехали написали что делали. Но это все в бумажном виде.

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

В принципе, можно попытаться решить эти вопросы детализацией работ.

Но. На названии самой работы (допустим, работа называется "Обслуживание компьютеров") - могут быть завязаны счета, фактуры, у клиентов эти работы прописаны в бюджетах и т.д....Подйту проблемы, вопросы, почему сменили название и т.д. С названием также связаны вопросы налогобложения, бухучета, а здесь они вообще не нужны..На названии не выедешь здесь (ИМХО).

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

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

Может, быть, оттолкнуться от этого ?

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

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

Почему ? Она у всех программеров стоит. Все программеры ее хорошо знают. Лицензирование на офис в целом дешевле, чем на 8. И 8-ку пока еще не освоили. Да и у клиентов тоже стоит 7.7. Да и неоптимальна 8-ка, вы верно заметили.

Но. Практически ни одна из возможностей 7.7, для которых она и была придумана - нам не нужна. Не нужны ни документы, ни проводки, ни план счетов. "Программа для программистов" должна помочь выработать, обкатать оптимальную структуру данных для работы с клиентами, и потом эта структура данных должна плавненько перелиться на базу SQL, под приложение написанное на C#. По моему, так будет само оптимально.

Таким образом, с инструментальной точки зрения мы пишем на 7.7 с прицелом на переход под C#+SQL. Посему не используем специфические возможности 7.7, а пользуемся только справочниками и подчиненными справочниками. Как оказалось, для описания структуры данных этого оказалось достаточно.

На самом деле работая с 8-ой мы тоже не используем ее прибабахи не регистры накоплений ни сведений, сложилось так что нам проще получить данные из выборки документов по каким то критериям, хотя соврал есть некоторые процедуры в которых используются регистры, 7 нам не подходит так же как и 8 если ее саму переносить на SQL то дорого, а нам нужно, еще раз повторюсь, доступ к базе через инет, а писать обработчики которые бы переносили с профки в SQL тоже мало приятного, да и двойная работа получается напиши на эске а потом тоже самое напиши на ПХП, поэтому пока ведем эксперементы, и доходит до бредовых идей, а почему бы не написать "платформу" на пхп, что то типа CMS. Все таки пришли к выводу что не хватает инструментов, эска хороша вот если бы она в стандарте с SQL работала бы, было бы замечательно

Советую отойти от бухгалтерских программ, не для этого они созданы.
Для начала посмотрите на программы CRM. Из бесплатных Sugar CRM

Верно. Это все из области CRM. Вот оно и слово нужное прозвучало.
Но. Покупать что-то неизвестное, когда я точно знаю, что мне надо ?
Alkor
Я думаю, начать решение задачи нужно с анализа сущностей и связей между ними. А уж инструмент дальше сам себя найдет.

Итак, основные сущности задачи.
Контрагент
Сотрудник
ФизическоеЛицо
Контакт
Событие (действие)
КонтактноеЛицо
Проблема
Email
СписокРассылки

Советую отойти от бухгалтерских программ, не для этого они созданы.
Для начала посмотрите на программы CRM. Из бесплатных Sugar CRM

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

Итак, основные сущности задачи.

Это все известно было еще до того как мы пришли к пхп, проблема действительно в инструментах.

Верно, CRM. Сейчас проанализировал все реквизиты решения. Нет ни одного (ни одного) реквизита, имеющего тип "число". Все реквизиты строковые. Значит, система имеет дело полностью с качественной, а не с количественной (как бухучет) информацией.

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

Дополнительные сущности задачи.
ВидКонтакта
ВидНоменклатуры
ВидПроблемы
ИспользуемыйПродукт
КлассификацияКонтрагента
Номенклатура
Пользователь
РезультатКонтакта.

Виды событий (действий) -
Замена сотрудника у контрагента
Импорт контрагентов из Excel
Рассылка по списку
Добавление адресов в список рассылки
Импорт контактов из Excel
Исключение адресов из списка рассылки
Назначение сотрудника контрагенту
Временная замена сотрудника у контрагента
Уточнение e-mail
Контакт
Импорт контактов из счетов
Рассылка счетов на оплату контрагентам
Поиск в любом справочнике по наименованию

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

ОК. Тогда далее -

Отчеты -
Отчет о контактах
Отчет о проблемах
Отчет о действиях
Отчет о контрагентах
Отчет о сотрудниках

ВидКонтакта
Звонок
Консультация по телефону
Вызов
Работа на месте (в офисе у клиента)

РезультатКонтакта
Счет-фактура после выполненной работы
Счет на оплату (по e-mail)
Счет на оплату (нарочно)
Акт сверки (по e-mail)
Акт сверки (нарочно)
Диагностированы проблемы (дистанционно)
Диагностированы проблемы (нарочно)

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

Без заполнения программистами (сотрудниками) отчетов о контактах ничего не выйдет. Откуда мы возьмем информацию о том ,что происходило между сотром и контром ?
Либо можно импортировать контакты из счета-фактуры/счета на оплату, при крайней его загруженности. Контакты можно импортировать из Ексель, и первоначальные данные о контрах скорее всего тоже. Ексель нам заменяет доступ по Вебу, программисты могут дома заполнить отчет в екселе и сбросить в офис. Даже можно не каждый день заполнять.

Контактные лица и Сотрудники - это слабая сущность, которая привязана к основной (сильной) сущности - ФизическиеЛица.

Вот я про что и говорю для регистрации контактов в УТ8 есть документ Событие, если его чуток отредактировать то получается самое то.

Закончил работу над спецификацией (рамочными требованиями). Выкладываю - может, кому пригодится.

Переношу в раздел 1С, чтобы не потерялось

Использовали продукт http://1c.rating.kz/products2_6.htm
Добавили прайс на услуги, листы выезда. Консультант решает что необходим "разбор на месте", ставит статус "передано программисту", соответственно из задач программиста можно увидеть всю историю "отношений"...