−2°C
завтра: −3°C
Погода в Перми
−2°C
утром−7°C
днем−9°C
завтра−3°C
Подробно
 63,71
−0.1329
Курс USD ЦБ РФна 23 ноября
63,7101
−0.1329
 70,52
−0.1790
Курс EUR ЦБ РФна 23 ноября
70,5207
−0.1790
PRM.Форум /Компьютеры Интернет Связь / Программирование /

Разработка программы для учета на перевалочной(складской) базе. (1с ?)

  • Ищется программист для разработки "с нуля" или настройки какого-нибудь продукта (типа 1с).
    Приблизительное ТЗ имеется.

    Карта стран где был

  • приблизительное ТЗ

    Карта стран где был

  • OFF

    А 1С надо будет устанавливать?
    "на перевалочной(складской) базе" напомнило недавнее "вагоноремонтное депо". Ничего личного.
    Извините.

  • нет не надо. Про депо не ко мне...

    Карта стран где был

  • Мне больше всего нравиться, что большинство клиентов искренне верят, что такая бумажка называеться Техническое Задание. А потом удивленно спрашивают почему столько денег за ТЗ неопхожее на эти бумаги.

  • как всегда вопросов в таких задачах два
    1. время реализации и сумма вознаграждения
    2. изменение "ТЗ" в процессе работы...

  • На второй вопрос есть однозначный ответ - ТЗ будет изменено. Так как то, что выложено - еще совсем даже не ТЗ, а просто наброски хотелок.

  • хммммм....

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

    Дело вот в чем. Сейчас программы пишутся с документации. Это значит если вы действительно можете формализовать все параметры и описать все процессы и связи, то вы можете программировать. Если не можете, надо искать специалиста который это может.

    Аттач посмотрел, это вообще-то плоская таблица. Где связи?

  • Предикат баз данных: факт хранится в одном месте.

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

    Совершенно не обязательно владеть языком программирования для общего проектирования реляционной базы данных. По проекту любой программист переведет документацию на SQL.

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

  • Ладно вам.. Поставить задачу вменяемому программисту - вечер-два под коньяк.:улыб:Не такая уж сложная эта логистика. Вы, видимо, с медициной не сталкивались - вот там водки правда много надо.:улыб:

  • В ответ на: Не такая уж сложная эта логистика.
    Нда...
    Логистика, она очень разной бывает...

  • Это как с переводом с языка на язык. Вы написали справку, хотите перевести ее на английский, например. Чтобы проверить нанимаете читателя-носителя английского. Он вычитывает: ну что, все правильно, все по-английски. Начинаете продавать и оказывается ваши клиенты не понимают что написано английским языком. Потому что редактор знал английский, но не ничего не знал из той области, для применения в которой написана ваша программа.

    Автору вопроса еще можно посоветовать забить на АРМ и АСУТП вообще. Дело вовсе не в технике, а в людях. В соседней теме вы можете убедиться в том, насколько быстро разобьются любые блестящие технические решения об отсутствие культуры делопроизводства.

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

    Сначала люди, потом компы. А можно наоборот? Можно, но люди вперед.

  • Чтобы дело не казалось таким простым, напомню что федеральные паспортные и транспортные базы появились совсем недавно. До этого базы были локальными и приходилось делать запрос через оператора базы в другом городе. Из-за чего, например, нельзя было зарегить автомобиль по месту проживания. Совсем свежая новость по базам: трудовая база наконец-то заработала. Теперь трудовые книжки не надо выдавать и поддерживать.

    Сколько понадобилось время на проектирование этих баз считая с БЭСМ?

  • К чему сей опус то? Автоматизировать бардак невозможно - это всем давно известно. Пример с переводом вообще не в тему. Если четко описаны все бизнес-процессы, то плевать на область автоматизации. Так же есть еще понятие цели автоматизации. Если ясных целей нет - снова получается бардак.
    Про базы паспортных столов - бред сивой кобылы. ИМХО, вы не в теме.

  • И насколько четко они прописаны в приложенном ТЗ? Или может быть это программист должен прописать выпив несколько литров коньяку, или что там грузят.

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

Записей на странице:

Перейти в форум

Модератор: