А завести доп реквизит на на документе типа НомерСчетаИзинтернета тип - строка уже религия не позволяет. Ну да сопоставление делать придется по нему - но таким образом эти данные ни как не влияют на учет в 1С.
на форме будет
Номер - Номер для 1С(генерируется самой 1С)
Номер для Интернет - тип строка (алгоритм присвоения ваш).

А вообще я бы еще порыл в стороноу соа.
в случае 1С8.1 - РТФМ по поводу веб сервисов.
в случае 1С77 - на сайте придется писать сервис,
и каким то макаром опрашивать его.

раз - По поводу АДО. харошая штука, но тут не сказали
где находится хостинг. Адо те помогет тольо в том случае,
если СУБД Сайта находится внутри сети, а если на стороннем
хостинге? а никак оно те не помогет иля я чет не докурил в мануалах,
или пара знакомых веб-программеров дятлы, но общаются с бд,
на хостиге посредство веб-сервисов, XMLHttp(Ajax) или скрипатми,
но не по АДО.

два - 1С8.1(8.2) имеет хароший механизм - интеграции СОА - веб сервисы,
приттом что как запрограммирую работу так и будут работать,
приэтом если выставляется счет(или другой документ) он будет
напрямую внесен в БД по запрограммированной логике.
если я цепляюсь к стороннему веб - сервису. то 1С8.1(8.2) сама разберет
файл определения веб-сервиса - только ссылку дай.

три - 1с7.7 не умеет по умолчанию работать с веб сервисами, но
имеет механизм оле -мне религия не запрещает по OLE с заданным
интервалом посретством соап клиента дергать с веб сервиса данные.
проблема только одна - передача массива SAFEARRAY по интерфейсу,
InitDone. решение -написание компоненты - обертки для клиента.
или использование сторонней компоненты.

четыр - для системных программистов -пишем службу, которая клиентом дергает,
данные из веб сервиса с периодом 5 мин(к примеру) и по механизму (COM,OLE)
колбасит документы в БД.

пять - в ИТС партнерской сказанно что без жесткой необходимости не рекомендуется,
ручное изменение нумерации документов.
проблема у тя могет возникнуть на мой взгляд в:
а) ренумерация - массово ты не напишешь алгоритм определения(ну вернее напишешь, токо попрышаешь)
б) Расперделенные БД и обмен инфой (префикс ИМХО -определяет БД, для того чтоб моно было отличить, где был выписанн данный счет(ид у них разные у всех)) просто возникнет путаница - оно те надо?

к тому же по теории БД - любое поле служит чтоб однозначно идентифицировать запись в таблице.
и твое решениее с префиксом немного идет в разрез с этим. скажи а отчего поле контрагент отдельное, а не в номере содержится?

ИМХО итог - безопаснее и логичнее в дополнительном поле писать номер счета с сайта,
ренумерация не затронет, в отчете можно искать будет по этому полю, без разбора
основного номера, в Распределенных БД - не думаю что сильная путаница возникнет.

Господин ПЖ>к тому же по теории БД - любое поле служит чтоб однозначно идентифицировать запись в таблице.

вот оно чо, Михалыч... а то сидели люди, потели, primary key придумывали...

з.ы умеешь же быть убедительным. выводы токо одни - завязывать нуно по ночам работать :)

vitkhvАлексей Серый
к тому же по теории БД - любое поле служит чтоб однозначно идентифицировать запись в таблице.
и твое решениее с префиксом немного идет в разрез с этим. скажи а отчего поле контрагент отдельное, а не в номере содержится?


Ухты, вы даже и теорию БД сюда припрели. Счас видмо религиозные войны начнуться. Только ответь мне на вопрос - почему это по вашему мнению 1С в id для уриба это делать можно, а нам в префиксах почему-то нельзя, и в чем будут собственно говоря проблемы, тем более алгоритмы стандартных конф хорошо заточенны под использования с префиксами. Или вы предлагаете по тихоньку добрую часть стандартных алгоритмов переписать, под отдельный реквизит для номера с сайта , а потом разместить номер с сайта на форме документа и получить в итоге огромный гемор с обновлениями?
Но красота архитектуры БД с точки зрения теории реляционых БД, для вас конечно важнее :)

а отчего нельзя то - я сказал что мне так проще...
можно все. в том числе писать в 1с БД напрямую... кто запретит то?

XenoXАлексей Серый
и твое решениее с префиксом немного идет в разрез с этим
Стандартная практика 1С использовать префиксы для нумерации документов.

Стандартные методы... типовые конфигурации...
расчетка типовая, себестоимости, которой плевать на постановление минфина...
токо вот учетная политика на предприятиях не типовая...
а может стоит всех под одну гребенку? а что...
типовые конфиги - лепота...
типовые методы(в т.ч стандартные) - красота...
кнопу тыкнул - и она все посчитала - сказка...
токо вот отчего то неработает это все... и конфа остается типовой токо на момент перехода + время адаптации людей - а потом ее допиливаю или фрилансеры, или программеры, или франчи... отчего так?
или мне только из 4х моих занкомых кто 1С занимается, довелось токо по номеру релиза узнавать..
что когда то это была ТиС... а теперь вполне стабильный прототип УТ - не спорю функциоанала поменее, но он и не требовался... и в таком случае я просто добавлял реквизит, чтоб самому не заптаться, что я где я и как я и зачем я добавил - притом что список изменений вел.

vitkhvАлексей Серый[quot vitkhv]
можно все. в том числе писать в 1с БД напрямую... кто запретит то?

Согласен с вами - чудо архитекторы и бич и хлеб 1С. Особенно любители на каждую новую сущность создавать новый реквизит в конфигурации (колонку в таблице БД).

А вы простите наверное в восторге от продуктов 1С? сори за оффтоп.
вы меня убедили - пойду переделывать адресное хранение на складе. Жаль конечно.. там столько сущностей новых появилось... в том числе и дефолтные значения в справочнике - надо было в код навеное пихнуть... и вы правы весь механизм проводок уже не типовой... как это 1С то не углядела :)

а по идее учет он у всех разный.