Долой рутину!

[Артём]

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

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

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

[Svetishe]

А чем Вы хотите меняться?

[Артём]

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

[Svetishe]

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

[Артём]

<b>Svetishe</b>, вот поэтому я вынес на обсуждение вопрос о создании стандарта. В принципе, я уже пытаюсь прогнуть некоторых поставщиков на предмет предоставления электронных документов, но лучше ведь сразу согласовать стандарт, удобный для всех, чем потом подгонять друг к другу многочисленные отраслевые. А они уже создаются: жизнь заставляет. И, мне кажется, сейчас самое время подумать над тем, как сделать их совместимыми.

Я вот только сомневаюсь - в тот ли форум влез с этим вопросом. Мож уместнее будет в "Программировании.."?

[stas®]

Артём, в "Программировании" правильнее поднять другую тему... Все программисты пишут на разных языках программирования, для разных операционных систем... В результате программы нельзя просто так переносить, приходится адаптировать. а то и переписывать. Правильнее выработать единый стандарт. И ОС, и языка программирования.

[Артём]

<b>stas®</b>, очень смешно
Но как в налоговую в едином формате документы подавать, эт
А как себе единым форматом жизнь облегчить - эт

[stas®]

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

[RedBrandt]

<b>stas®</b>, Штрихкоды - работают, визитками с сотового на сотовый большинство обменивается, 1С - в большинстве бухгалтерий, Винды - также, с кредиток информация считывается и защищена, электронные подписи существуют, вирусы, правда, также и промышленный шпионаж никто не отменял.
В советские времена мне пришлось поработать программистом АСУ в НПО, средний уровень тех, кому за 30, (да и за 20-25) не впечатлял, экономить могли байты, а понятность информации для потребителя - нестильно. В 1985 году большинство отлаженных систем были на перфокартах и перфолентах, про внедрение какой системы обмена данными между потребителями в таком виде можно было говорить? Я хоть и работал на Искре-555, но во время аврала понабивал эти перфокарты, ощущение непередаваемые. Однако в министерство отчеты и планы шли на магнитных носителях и с ними нерешаемых проблем не возникало.
Я уверен, что, со временем, будут разработаны менеджерские терминалы, и, соответственно, будут разработаны стандарты обмена данными. Денег это принесет не меньше, чем сотовая связь, TCP/IP, Blue Tooth, SCSI и т.д.

[RedBrandt]

Я вот только сомневаюсь - в тот ли форум влез с этим вопросом. Мож уместнее будет в "Программировании.."?

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

[RedBrandt]

<b>Svetishe</b>, Как совершенно правильно сформулировал наш сисадмин DSK

"ну, например, существует много разных "почтовых программ", (Outlook, TheBat! и т.д.), но при этом все они меж собой меняются сообщениями без проблем, потому что унифицирован сам тип сообщений. а вот другой, более близкий к этой проблеме пример - сколько сейчас существует компьютерных стандартов изображения? дофига, просто писатели соответствующих программ вынуждены включать все стандарты в свои программы, чтобы не отстать от конкурентов. чуть лучше ситуация с текстовыми документами - их меньше (стандартов), тем не менее как минимум doc и pdf живут пока вместе. в общем эта проблема общероссийского масштаба как минимум, если речь идет только о России, если шире - значит мирового. хотя не факт, что такого стандарта за рубежом уже не существует, просто как обычно "мы еще невкурсе""

[stas®]

1С - в большинстве бухгалтерий,

<b>RedBrandt</b>, и чем из 1С ты обмениваешься с поставщиками/потребителями в электронном виде?

[RedBrandt]

<b>stas®</b>, Если через FineRiderBank считается, то платежками. А зачем это тебе?

[Aquad]

Тема очень актуальна...

Существуют унифицированные форматы обмена данными.
К примеру, тот же http чем не унифицированный стандарт ?
Сколько различных браузеров с ним работают - десятки, если не сотни.
Или его дитятко XML ?
Останется только одна проблема - трансляция его в/из собственных форматов различных программ. Но это уже не такая сложная задача, если народ начнет ее применять (унифицированную форму обмена)... то дело само пойдет (с написанием трансляторов).
Это что касается "программирования" данной задачи.

Вот только один вопрос: а что будет с "раздутием" номенклатурных единиц ? Одни поставляют коробками - а другие пачками - а третьи штуками ?
Здесь надо думать над синхронизацией кодов и наименований...
Хотя во многих областях такое уже есть, но их тоже придется стандартизировать...

[RedBrandt]

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

...есть принцип, по которому можно шифровать, алгоритм, если угодно. а вот есть ли конкретная реализация стандарта для товарных документов - не знаю...
...наверняка - надо искать на сайтах ISO - мировые стандарты. или на ГОСТах или как они там называються нынче...
...все упираеться в стандартизацию...

Я так понимаю что надо искать тех кто силен в стандартизации и метрологии. И ставить задачу. Какие данные необходимы кодировать и передавать?
Реквизиты поставщика, реквизиты получателя и все "тело" накладной? Этого хватит? Или вводя такой стандарт надо предусмотреть дополнительную инфу? Какую?

[Артём]

... вводя такой стандарт надо предусмотреть дополнительную инфу? Какую?

В смысле: какие поля должны заполняться? Если да, то это: цены, реквизиты контрагентов, наименование, артикул и характеристики товара, код EAN, признак, тип, изготовитель, ГТД, сведения о сертификации (это несколько полей: рег. №, учётный №, кем выдан, когда выдан, срок окончания действия), логистические параметры (тоже несколько полей: вес, объём, количество в упаковке (коробке), количество в групповой упаковке, количество на поддоне), + отраслевые параметры (мощность для электротоваров, срок годности для продуктов и таблеток и т.д.).
В принципе, когда мы передаём 1С-справочники в филиалы, вся эта информация + внутренняя передаётся в электронном виде (в *.txt).
.dbf тоже импортируется в 1С, по этому формату мы дали поставщику прилагаемое задание

[Grey Bird]

Есть мнение что надо задачу разбить на три части.
И исходя из этого строить модель передачи данных.
объекты:
1.бухгалтерская программа, которая умеет выгружать данные в произвольном своём собственном формате.
2.модуль который умеет преобразовывать этот формат в формат сервера обмена.
3. сервер обмена, который обеспечивает проверку, упаковку, доставку информации. Возможно умеет ставить на отправляемую корреспонденцию ЭЦП.

Необходимо продумать:
1. уровень передачи между бухгалтерской программой - (модуль сопряжения в сервере обмена задан разработчиками бух. софта.
2. уровень передачи между модулем сопряжения и сервером обмена.
3. уровень передачи между серверами обмена.

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

[Grey Bird]

В догонку.
формат между модулем сопряжения и сервером обмена должен быть максимально "прозрачным",
текстовым, с минимумом служебных полей(длина, и возможно тип переменной).
что то вроде:
INN(12)=
RS(20)=
Формат обмена между серверами обмена, может быть произвольный, удобней всего будет если формат будет строиться последовательно, т.е.
вывод данных->ЭЦП->архивирование->передача данных
С законченным результатом на любой из стадий.
в результате, например можно взять файл до передачи данных и записать на дискету и отдать клиенту. ;-)

PS. несколько не так глобально, но уже почти работает: 1с->печать документа на linux server, там хватаем полученый spool, преобразуем в pdf, pdf отправляем по е-mail в сторону контрагента.
Можно не преобразовывать в PDF а швырять spool в формате prn(естественно его предварительно заархивировав). При достаточно похожем принтере(НР laserjet чего-нибудь) у получателя достаточно сделать на автомате "copy /b prn file.prn"
Это получается всяко лучше передачи по факсу. ;-)

[Grey Bird]

Ни для кого не секрет что в организации обычно с контрагентами общается не бухгалтерия, поэтому документы попадают в бухгалтерию "кривые" и с большим опазданием.
Возник вопрос, разрешено ли в платежке в поле назначение платежа писать произвольную дополнительную информацию, например "документы присылать на адрес:ХХХХХХ"
Или это запрещено?

[Артём]

Ещё мысль: надо предусмотреть (хотя бы) 2 вида документов: Справочник товаров, содержащий неизменные реквизиты товара и актуальные изменяемые, и Документ поставки с изменяемыми реквизитами (цена, ГТД, данные о сертификации, № партии, срок годности и т.п.)

[RedBrandt]

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

[Aquad]

RedBrandt,

ИМХО, Все общие данные должны содержаться в глобальной сети... Например, классификатор банков, что расположен на сайте РосБизнесКонсалтинга.
К общим данным я лично могу отнести Контрагентов (т.е. справочник юр. лиц), Товары (вот с ним то и будут большие проблемы, как я уже и писал) причем он должен быть классифицирован по их видам (и вопрос соответственно сколько может быть видов, подвидов, подподвидов, ... под...подвидов)...

[Grey Bird]

Мне кажется Вы не правы, пытаясь придумать схему которая базируется на моделе в которой есть "центр-который-всё-знает". Мне кажеться что для успеха и быстрого распространения система должна быть:
а) децентрализована(Например посмотрите на успех интернет, фидонет. В случае такой модели справочники можно сравнить с поддержкой DNS адресации. Производитель держит только те наименования которые у него "в подчинении", остальные к нему приходят от поставщиков.)
б) открытость и простота кода.
Громоздить что то на основе ОКДП - утопия! Только неполный справочник весит около 6 мб.

PS. По большому счету безразлично называние однородного товара, главное чтобы оно оставалось НЕИЗМЕННЫМ по всей цепочке продавец-покупатель.

ИМХО, Все общие данные должны содержаться в глобальной сети... Например, классификатор банков, что расположен на сайте РосБизнесКонсалтинга.

Еще одно замечание - система дролжна позволять работать в "offline", типа раз в неделю по флопинету передаются данные.

[Артём]

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

Те, кому это выгодно - производители или импортёры: они же сертифицируют, растамаживают (а это всё процессы куда затратней, чем поддержание справочников).

[Артём]

...Вы не правы, пытаясь придумать схему которая базируется на моделе в которой есть "центр-который-всё-знает". ...Еще одно замечание - система дролжна позволять работать в "offline", типа раз в неделю по флопинету передаются данные.

Центр должен не всё знать лучше участников, а служить участникам инструментом для выработки общей позиции. А иначе нам не избежать того, что фирмы будут переименовывать товар и т.д. Сейчас это происходит сплошь и рядом. Появляются вещи, о которых раньше никто не знал, и каждый называет их как хочет. На каждом этапе движения товара народ хихикает и придумывает что-то своё, типа адекватное. Тут нужен механизм формирования названий товара, позволяющий 1) оперативное обсуждение названия нового товара, 2) безболезненное усовершенствование названия, не препятствующее идентификации. Т.е. речь не о централизации, а о коммуникации.
Чем так уж плох ОКДП? Это же классификатор, его никто не будет гонять по цепочке продаж.
Допустим, я - торговая фирма. Появляется новый поставщик. Мне от него нужен справочник с его товарами, чтобы узнать его ассортиментный потенциал и сравнить цены. Вот он и присылает мне не свой прайс по факсу, а справочник в электронном виде. И там нет ничего лишнего, кроме, например, канцтоваров, которые меня и интересуют - ни капусты белокочанной, ни машин электрических сверлильных (это ж надо так дрель обозвать!). Я закачиваю этот справочник в свою систему заказов, отмечаю позиции, которые буду заказывать постоянно, они регулярно заказываются. В ответ на мой заказ поставщик присылает счёт, я его сравниваю со счетами других поставщиков, корректирую (в т.ч. убираю позиции, которые другой поставщик предложил мне дешевле) и даю согласие на отгрузку. В момент отгрузки поставщик посылает мне электронный Документ поставки, из которого в моей бухгалтерии формируется приходная накладная, и на основании которого заполняются в моей базе необходимые поля (наименование, характеристики и т.п.) и/или актуализируются изменяемые данные (ГТД, данные о сертификации, номер партии и срок годности и т.д.). А если в мою фирму обратился клиент со специальным заказом, то, имея в базе данные о всех товарах, имеющихся у моих поставщиков, я могу сразу определить возможность поставки, а, имея онлайн с поставщиком, могу сразу назвать цену и срок поставки.
А ОКДП пусть держат у себя на компе те, кто формирует названия. Кроме них, он никому и не нужен.
Насчёт офлайн-режима согласен, такой нужно предусмотреть. Лет 10 это будет актуально.

[Grey Bird]

Еще раз, идея центра порочна по своей сути.
Предположим, настало "светлое завтра" и системой пользуются десятки тысяч фирм... Внимание вопрос: какой сервер, каналы передачи данных и т.п. инфраструктура потребуется? И кто за это будет платить?
Или ситуация, изобрел предприниматель из Урюпинска какую-нибудь новую фигню, сколько он будет ждать пока его внесут в это "чудоклассификатор"?
Все гораздо проще. Есть производитель товара или импортер. Это нулевой уровень, корень, откуда растет всё дерево операций с этим товаром в стране. Он диктует своё название всем нижестоящим контрагентам, и никаких проблем. Вкаждом документе есть название товара. Для надежности можно предусмотреть подпись(например CRC-32) на номенклатурную единицу, от "корня". Если наименование придумал не производитель, то подпись не ставится.
Для особо клинических случаев используется таблица синонимов.

Изобретать систему надо такую что бы она могла работать при любом количестве контрагентов от 2 до +бесконечности ;-)
И чтоб, если ей удобно пользоваться, разрасталась как плесень в сыром месте сама собой не требуя усилий. ;-)

[Gang]

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

[stas®]

Дык... Раньше это называлось Госплан

[Svetishe]

Люди в эти супермаркеты не ходят - т.к. ч/з мобильник (ну или еще какое миниатюрное устройство) делают заказ и оплачивают его.

Люди даже этого не делают, это делает холодильник.

[Aquad]

Grey Bird,

На РБК так и есть - один раз скачал и работай пока не захочешь обновиться.