Светлая голова, откликнись

Есть 2 базы 8.2, обе на SQL
счета колотятся в обоих базах
нужно как то сделать так, что бы нумерация была сквозная, без префикса базыи не важно где вы создали счет
Кто как бы решил такую задачу, важна скорость присвоения номера и простота реализации

(0) я предложил бы не делать мозги и работать в одной базе. В случае неповиновения послал бы в пень

Инет есть?

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

(0) Зарезервировать номера в течении дня, допустим в первой сегодня с 1000 во второй с 2000, в конце дня перенумерацию

как вариант сделать третью базу (не 1с)

а вообще я-бы решал задачу через выделение квот (диапазон номеров), например выдается на пол дня вперед, потом еще на пол дня.

(2) да, есть

(3) ув.господин, данный вопрос не рассматривается. Просто представьте что нужно сделать и как бы лучше и оптимальнее

нумерация строго в соответствии с временем?

(7) да, потому что на основании счета делается акт об указании произ услуг и счет-фактура

(5) зачем не на 1С? как квота обеспечит сквозную нумерацию?
(6) ты точно читал внимательно? Какой вариант не рассматривается?

(8) и дальше что? Из чего из этого следует, что нумерация должна быть сквозной и не содержать префиксы?

(9) вариант послать все в пень

Требование бух учета, сквозная нумерация счетов-фактур + бухгалтерия оч трепетно за этим следит.

(0) А порядок строго обязателен резервирование не рассматривается номеров?

рассматриваю вариант на общий ресурсе завести текстовый документ или dbf таблицу и туда писать и оттуда получать посл номер, но как решить вопрос с транзакцией если одновременный запрос пойдет из двух баз пока не знаю.
(13) поясните вашу идею

при открытии нового документа в одной из баз бронировать себе номер в РС, во второй выполняешь поиск по номеру который присвоился автоматически + 10 номеров вперед, находишь из них пустой присваиваешь - снова бронируешь

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

(14) медленно очень будет

(12) О, уже и счетов-фактур. А были только счета. Какие такие требования бухучета?

(18) номер счета потом соответствует номеру акта и номеру с-ф.

(12) Сквозная означает, что не должно быть двух одинаковых номеров. У меня 8 филиалов и все колотят Счета. На каждый филиал свой превикс и вперед.

(19) А если на основании счета не выпишут реализацию (ее просто не будет)?

комом подключить друг к другу и проверять номера перед присваиванием у кого больше +1

(19) Может нарушиться хронология номеров с/ф, если порядок выставления счетов и с/ф будет неидентичен, а он таки будет, т.к. основанием для с/ф служит вовсе не счёт

не могу на это смотреть...

идею 22 поддерживаю !

На СКЛ завести дополнительную базу с табличкой где хранить текущий номер.

(22) А комом можно сразу во вторую базу записывать параллельно?

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

для начала надо понять на каком этапе будет нужен номер счета

(27) зачем записывать нужно просто глянуть номер и по логике записать...

(29) номер нужен на момент записи счета

Одной базе - четные, второй нечетные)

если нужно сразу при создании. для печати допустим. тогда заводим табличку на СКЛ как в (26) и читаем/пишем туда с блокировкой. могут случится пропуски номера, но от этого никуда не денешся когда разнесены базы.

(31) на момент записи для какой цели? если не для печати, то номер можно потом присвоить. в фоновом режиме.

(6) Ну так и в чем вопрос тогда?
Щемись в другую базу, получай номер, записывай.

(32) это при условии одинакового количества счетов в базе, а так будет через один...

(32) лучший ответ в ветке! :)

(32) сквозного учета не получится в одной базе колотят намного больше чем во второй. но идею я оценил. крутая!!!

Представительские расходы?

(37) если пропускать номера можно, тогда их можно присваивать в зависимости от времени и даты. При совпадении - (32)

(36) Ага, а потом появляется ВНЕЗАПНО 3-я база )))

(40) как два пальца об асфальт:
База 1 выдает номера, которые %3=0
База 2 выдает номера, которые %3=1
База 3 выдает номера, которые %3=2

Решение 100% масштабируемо - это можно даже без изменения кода при добавлении базы реализовать.

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

Одинесники такие затейники :))
Чем (34)-то не устраивает?

(0) Это конечно изврат) НО
Даю идею - простенький веб-сервис который выдает последний номер. Во второй базе в конфигураторе прописать ссылку на него. Работать должно быстро, можно блокировку поставить, чтобы исключить здвоение номеров одновременно введенных счетов.

(44) Это должна быть вообще левая база, в которой 2 объхекта. Собственно веб-сервис и документ "Выданный номер". По обращению записывается новый документы и возвращается его номер :)

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

выдавать номера по инету и стучаться в другие базы - бред (без обид авторы).
в одном офисе сервак упадет, все встанут?

(45) я тоже об этом подумал, но уже после того как нажал отправить)

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

(46) Если в одном офисе инет упадет, то задача нерешаема в принципе.

Присваивается номер с префиксом.
Периодически, допустим раз в 15 минут, какой-нибудь скрипт анализирует обе базы базы и перенумеровывает документы с префиксами.

(48) То есть на словосочетание из (0) "что бы нумерация была сквозная" как бы начхать?

(50) Что за ерунда? А то, что уже напечатано, кто раз в 15 минут перепечатывать будет?

(49) с чего бы? сквозная обеспечена.
"подряд" кому надо? человеку для посмотреть?
для этого при большом желании можно потом отдельный реквизит заполнять "человеческий номер"
в остальном префикс - решение всех проблем.
раз нельзя текстовый пусть будет числовой.
100% масштабируемо. 100% независимо от каналов связи.

(48) да. но не решает ситуации когда баз три или больше.

(52) Если создают документ и сразу печатают, то вариант не подойдёт. ;)

(49) имеет - (32)
(54) еще как решает - (41)

(48) С четырьмя базам уже не сработает :)

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

(57) это с какого это полового органа? еще как сработает. Повторяю - даже можно сделать так, чтобы при создани новой базы код менять не надо было

+(57) Хотя, сработает, гоню..

(59) Но ведь количество используемых баз где-то всё равно хранить надо. И начальный номер.

(61) вопрос на тройку: а не план ли обмена для этой цели предназначен?

номер числовой, в кода УстановитьновыйНомер() до тех пор, пока он не даст при делении по модулю нужную циыферку. Только это делать надо ПриЗаписи и отключить автонумерацию у формы.

Если обязательна хронология - тогда только одна база (пофиг что там ввод первички или только генерация номера будет)
если не критично - что угодно хоть (32) хоть цифровой префикс
... да хоть обмен документами между базами организовать по регламенту раз в 5 секунд

Предвижу лёгкое  удивление ГБ ТС  от
Счет-фактура №100500 от 31.05.2013
Счет-фактура №13 от 01.06.2013

(65) при таком дисбалансе вторая база и не нужна - этих бездельников можно в первую загнать

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

110000001
120000001

только в учетной политике прописать на всякий.

(66) Вторая база работает летом :)
Счет-фактура №100508 от 30.09.2013
Счет-фактура №353427 от 01.10.2013

почему мою идею квотирования никто не поддержал?

с утра на основании статистики создаем в обеих базах пустые документы со сквозной нумерацией, по количеству например до обеда. дополнительно ставим префикс "П"

база 1, номера П1, П5, П10
база 2, номера П2, П3, П4, П6, П7, П8, П9

бухгалтер берет самый младший номер с префиксом П и когда вбивает данные убирает префикс "П".

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

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


зы
потом автор скажет "срочно нужно впихнуть задним числом одну СФ, как сделать????"

а я знаю ответ, при квотировании НУЖНО оставлять дырки и помечать такие доки на удаление.

У меня совет тем бухам: не подпускайте к своим базам ололо-одинесников. Один счет, один акт, одна СФ, все с одним номером - вменяемые бухи такого не могли придумать.

(70) это называется "вынос мозга адинэснику".

(70) ты не поверишь я такие требования переодически встречаю

(70) Хуже невменяемых бухов - только потакающие им одинэсники

(73) Да ладно... им же бумажки неудобно раскладывать... одинэсники должны решить эту проблему...,
а кто ещё то?

(0) Сделай им какой нить дополнительный номер...присваиваемый при закрытии центральной базы...)

(0) 1С это не потянет - сырая еще. Нужен SAP - в нем 100500 филиалов в разных странах работают в одной базе!

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

(0)Глупости. Прочитай, что в учетной политике прописано. Пропиши использование префиксов и всё. Всё остальное от лукавого. Если программиста пускать в учетную политику, он много еще напридумывает. Лишь бы на иглу программиста подсадить владельца бизнеса.