Как перегнать накладные в dbf? #7059

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

поимаешь гемороя с ДБФ... и продумай вопрос с нумерацией доков  и кодов справочников...

перетащить это фигня, вот как ты справочники синхронизировать будешь

Для этого есть специально написанные обработки, в частности Универсал. Можно написать и свою, но чуть-чуть дольше будет :)

Привожу свою схему (отработана и отлажена). Может конечно и не моя, но додумался до неё сам. Итак На этапе формирования пакета данных для отправки делаешь так 1. файл с шапками документов - все реквизиты-справочники - пишешь в файл код, все реквизиты перечисления - строку 2. Файл с ТЧ документов с полем "документ", в который пишешь номер документа от которого эта ТЧ 3. Файл с данными по контрагентам, которые участвуют во всех документах, которые та передаёшь 4. Файл с товарами - аналогично контрагентам Загрузку делаешь так 1. Загружаешь и проверяешь справочники (синхронизируй по коду с проверкой соответствия наименования) 2. Новый документ - запись из файла шапок-заполняешь все реквизиты документа, какой реквизит - справочники ищешь в соответствующем справочнике. Когда дохожишь до ТЧ открываешь файл с ТЧ документов и ищешь по документу-владельцу соответствующую ему ТЧ - заполняешь. Всё.

Синхронизация по коду - неверное решение...

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

Diter-у Спасибо. В принципе понятно. 427-му и sam_sam: тоже спасибо, но вопрошаюший, как правило, жаждет позитивных предложений.

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

Спорим не наловит. Объясни почему? Только не голословно а с примером. Единственная ситуация, которую эта схема не отлавливает, если в наименовании элемента справочника есть в начале или конце пробелы, т.к. используется СокрЛП. Но это во-первых редкость, во-вторых - неправильно и кривые руки у юзеров отбивать надо.

Громобою. Универсальную обработку на хипо "бездвоздмездно" не дают скачивать.

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

Опять пустой трёп. Я же просил на конкретном примере показать как можно поймать дубля при двойной проверке (и по коду и по наименованию)?

Эта схема работает в трёх моих разработках у реальных клиентов уже в течении месяца. Никаких дублей замечено небыло. Все справочники заполняются на нескольких машинах. Весь обмен идёт через dbf. Ни разу, я повторюсь, дублей выявлено небыло.

При загрузке записали новый элемент (1, ИмяДляДэбильногоПримера)   В базе источнике изменили наименование на ИмяДляДебильногоПримера В базе приемнике при загрузке создается новый элемент (2, ИмяДляДебильногоПримера) В базе источнике изменили наименование на ИмяДляПридурковатогоПримера В базе приемнике при загрузке создается новый элемент (3, ИмяДляПридурковатогоПримера)   В сухом остатке получаем: в базе-источнике все остатки/движения на элементе (1, ИмяДляПридурковатогоПримера) в базе-приемнике те же остатки/движения разбросаны по ТРЕМ разным элементам...   Если это не дублирование, то...

Извени, но это уже явные косяки. Если все будут менять имена и коды во всех базах, то бардак будет при любой схеме синхронизации. Даже если ты будешь использовать внутренний ID МОДа от ПиБи всё равно ничего путнего не получится. Пользователь то работает не с внутренним кодом а с именем клиента и ты хоть лопни, но доказать ему что Вася это Петя только исправленный ну никак нельзя. Если разбираться, то это тот уровень защиты от дурака, когда программно ты ничего не сделаешь. Нужны административные решения. Вплоть до запрета ввода новых элементов справочников в перефирийных базах. Предупреждаю крики - это для примера, хотя один мой клиент заказал такое при обмене с удалённым складом. Всё равно все заказыоформляются и печати ставяться в центральной бухгалтерии. Вот только там и вводили новых контрагентов, а перефирийные базы - нет.

попробуй урбд

(+15) Кроме того забыл указать, что все вновь созданные элементы создаются в папке "Неопознанные при загрузке", а все существующие элементы, у которых был изменён код - в папке "Изменённые при загрузке". Юзеру остаётся только разобраться с ними. Опять же обмен между базами предполагает обмен хотябы раз в несколько дней, лучше конечно каждый день, а то и раз в несколько часов. При этом количество новых клиентов и товаров обячно не превышает десятка-двух. Уж разобраться с ними не проблема ни времени и ни сил. Было бы желание.

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

Пробовал синхронизировать и по ИНН и по ОКПО и по р/с всё не то. Эти реквизиты относятся к тем, которые бухи не всегда заполняют. Я вот ставлю "клиент-банк" так не могу юзеров заставить повводить ОКПО, МФО и р/с. Так тут деньги завязаны, что для бухгалтера святое. А на косяки при обмене им вообще начихать. Звонит вчера часов в 9 вечера клиент и говорит "программа отказывается добавлять контрагента в справочник". Спрашиваю "Чего пишет" (нужно отметить, что воткнул проверки и защиту от дурака куда только дотянулся). Говорит "Пишет, что неверное имя контрагента". Спрашиваю "Какое имя", отвечает "ЗнакБольше-меньше" (т.е. вообще без имени). Я спрашиваю "А зачем вам документы с таким контрагентом?" отвечают - "А решили списать товар, проданный за наличку, и чтобы никого не ставить завели нового контрагента с пустым именем, чтобы НЕ ВЫЛАЗИЛО В ОБОРОТКЕ". Спрашиваю "А вы оборотку то смотрели после этого?" ответ "Нет, а зачем". "А затем, что там пустой контрагент всё равно появится". Говорят "Быть не может". И этот диалог происходит при условии того, что я русским языком рассказывал, что нельзя вводить пустых контрагентов или контрагентов, имя которых начинается с пробела.

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

Если ставил "защиту от дурака", то почему при записи не проверяется пустое наименование контрагента?

какое же однозначное отображение если всё равно в одной базе увидят ИмяДляДэбильногоПримера а в другой ИмяДляПридурковатогоПримера и ИмяДляДебильногоПримера? А? Да код один, он и в моём случае один, но имена то разные. Ты знаешь как то не подумал, что юзер может до такого додуматься. Как раз сегодня поставил запрет выгрузки таких документов с пустыми именами элементов справочников.

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

Не сложно но выгружать лучше в txt формат я выгружал при помощи команды ВСтроку ИзСтроки главное здесь не запутаться делаешь одельные функции для выгрузки справочника (со всеми реквизитами) и документов (шапка и табл) перебирая все метаданные если все сделать правельно то получится универсальная выгружалка и загружалка а лучше использовать даже не txt а xml

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

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

У меня тоже проблема была. Нужно было накладные с одного компа на другой комп перегнать каким-нибудь ёбразом. в принципе я поступил способом dbf-ок, ориентацию по номенклатуре осуществлял кодами (я просто номенклатуру перегнал с одной базы в другую). Сразу скажу: -Я так думаю тут ничего сложного нет. Если что задавай вопрос по конкретнее, постараемся ответить!!! :)

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

Что характерно - никто это не воспринимает... Глас вопиющего в пустыне... Предпоследние четыре поста  - откровенное сравнение размеров...

Прогульщикам будет выдаваться отдельно.... маленьких размеров.... съемный...