1) Как програмно создать документ на основании текущего, не отрывая его при этом?
2) По какому принципу работает интерграция с клиент-банком?
| ||
Тема: Пару вопросов
Пару вопросов
1) Как програмно создать документ на основании текущего, не отрывая его при этом?
2) По какому принципу работает интерграция с клиент-банком?
Denn wo euer Schatz ist, da ist auch euer Herz
1) Ну для этого давай разберемся сначала что такое ввод на основании.
Поидее связь документов обеспечивается примерно следующим образом :
в документе который ты хочешь ввести есть реквизит типа документа "родителя", т.е. если ты просто напишешь :
Док.Новый();
Док.ДокументРодитель=ДокументОснования;
Док.Записать();
они будут у тебя уже связаными.
Сама процедура ввода на основании это просто , как бы так получше выразиться ... "формальность" для удобства отслеживания.
т.е. есть процедура ВводНаОсновании(ДокОснование), которая вызывается при интреактивном вводе на основании , где очень удобно отслеживать значения реквизитов документа основания, но если ты нигде в документе не присвоишь какому-то реквизиту этот документ (например заказ=ДокОснование)
связи с документом основания у тебя не будет ...
вот такие пироги....
2) здесь все зависит от программы банка ,
мне встречались примерно следующие механизмы :
- в программе БК ты делаешь выгрузку , в 1С загрузку в текстовом формате
- в БК при получении выписки где-то формируется фал , который ты потом парсишь как тебе нужно
- в БК в формате ДБФ (или любом другом) хранятся файлы , ихний админ говорит тебе какой файл и за что отвечает , а ты уже сам делаешь обработку по импорту
и т.д.
т.е. единого механизма нет ... всегда приходится подстраиваться по каждый бакн в отдельности
Кратк. - сестр. тал. !
Мдя, 1с - отстой канкретый. Не думал, что ставит такие ограничения програмисту.
Вообщем идея была такова, Утрирую применительно к торговли чтоб было понятней:
Приходит клиент и берёт товару на n-ую сумму. Формы оплаты следущие:
1) наличман;
2) перечиление гривневое;
3) перечисление валютное;
4) кредитка.
1 вариант) при сохранении РН на основании расходной автоматом создаётся ПКО
2 вариант и последующие...) бух формирует отчёт "неоплаченные доки", в котором можно создавать счета-фактуры, в табл части которых, товар по многим неоплаченным РН, которые должен оплатить данный плательщик,
Думаю понятно изложил мысль. )) Может тут изобритаю лисопед. Есть такой вариант (при помощи сторонней компоненты rainbow): http://www.dinform.ru/kuban/htmls/public_htmls/9-114684.html
Я же пошёл по пути наименьшего сопротивления )) - сделал на форме РН пимпу "Печать ПКО" - которая создаёт ПКО на основании данной РН, под конопкой след код:
OpenForm("Document.ПКО",, CurrentDocument())
Позже немного сложнее будет - будет проверка на наличие подчинённых доков - если да, то отрываем подчинённый ПКО, нет - его создаём
Denn wo euer Schatz ist, da ist auch euer Herz
вообщем - конструктор, есть конструктор. Стандартные болтики, гаички, планочки и ффффффффффсссссссёёёёёё.
это получение инфы, а в КБ передать инфу (перечислить организации)?Сообщение от Mulder_1
Denn wo euer Schatz ist, da ist auch euer Herz
не в обиду ... так говорят люди катоторые ваще не разбираются в 1С
или знакомы с ним очень поверхносно (судят обычно по сравнению с другими языками)
на самом деле механизм очень сильный , если конечно потратить немного времени (книжки там почитать разные ) и втыкнуть в него (причем необходимо отойти от стандартного образа мышления программиста)
теперь по поводу проблемы ... ты используешь стандартную конфу или пытаешься написать свою ? В стандартной , надо много перелапатить шоб такого добиться - если своя - здесь вопрос другой (требует более глубоких уточненийи . возможно более универсальных решений пробем)...
поверь мне на слово RAINBOW - это не решение твоей проблемы , (судя по коду OpenForm("Document.ПКО",, CurrentDocument()) ..) ), если уж хочешь действовать нестандартно - есть много других более "удобных" механизмов
по поводу БК , опять же нужно созваниваться с банком , вызванивать ихних программистов , и выяснять : есть ли такая возможность, все зависит исключительно от программы БК (чаще всего можно обмениваться по OLE , но опять же только в том случае если программа БК это позволяет)
было у меня и такое : программа БК работала по TMAIL-у (старый такой BBS ный механизм был), там достаточно положить файл в нужную директорию , а программа сама его забирала
Кратк. - сестр. тал. !
Был в тот день под впечатлением, когда целый день долбился с тамошим понятием "Ввод на основании".
По ходу вопрос:
Может ли один документ быть основанием для многих документов. Т.е на практике - организация (КонтрАгент) берёт товар по нескольким РН. А после мы выставляем счёт по этим всем РН?
Т. е хотелось бы отлеживать проплату всех первичных документов по такой цепочке:
1) РН -> ПКО
2,,,) РН -> Счёт -> БВ(Банковская выписка)
Не спорю, что конструктор сей позволяет быстрыми темпами описать все бизнес процессы ))), однако недостатки при этом следующие:
1) непродуманный механизм «клиент-сервер’а”;
очень много того, что приходится делать в монополе, а именно:
2) доработка модулей;
3) резервное копирование;
4) перепроводка;
5) (пере)индексация;
7) непродуманный механизм перехода на новый период (закрытие месяца), при котором надо всех выгонять
кроме всего прочего
6) кривой интерфейс
- отсутствие штатных средств сортировки таблиц по столбцам;
- отсутствие штатных средств раскраски ячеек;
- отсутствует возмодность изменения порядка колонок драг-энд-дропом по аналогии с проводником;
- недоступность изменение элементов форм, при ресайзе формы (т.е. когда пользователь изменяет размеры формы, она ведёт себя несколько неописуемо );
7) неоптимизированные запросы с БД
8) отсутствие штатных средств удаления мусора с БД
Согласись, что сегодня выглядит, честно говоря, несколько диковато что необходимо всех пользователей выгонять чтобы делать, скажем, резервное копирование или доработку модулей или переиндексацию...
Верно, это конфа нестандартная, пишется с нуля (турагенство+авиаагенство), естественно многое берётся со стандартных конф
Например? Я лично не вижу смысла кому-либо из пользователей (тому же кассиру) перепроверять реквизиты ПКО, если сумма "К оплате" или реквизит "Плательщик" взят из РН функцией "Ввод на основании". Может я чего то недопонимаю.
Ситуация: Подходит чел к кассе и говорит:
"Меня звать Пупкин, я только что взял товару на n-ую сумму".
Кассир открывает ПКО и проводит его простым одним нажатием кнопки "Провести"
Это ещё предстоит, пока сделаю банковскую выписку руками
Denn wo euer Schatz ist, da ist auch euer Herz
Да может , т.е. при этом тебе нужно просто в каждом документе "ребёнке" держать реквизит со значение документа "родитель"
не согласен , механизим как раз продуманный (особенно если работаешь на SQL)
это скорее особенность ... т.е. поидее ты используешь плоскую базу , которая является псевдо объектно ориентированной благодаря движку. Для сохранения целостности данных и корректоного (стабильного) обращения к ним, просто необходимо внести такие ограничения , но даже такое ограничение на мой взгляд не является существенным ... но по этому поводу можно долго спорить
В конфигураторе : Администрирование -> Сохранить данные
Если делаешь 1С-ный пакетный файл , это может делать автоманом .
Но я лично предпочитаю простой батник построенный на rar-е, который просто архивирует всю директорию
Есть стандартная функция , если она не пожходит , всегда можно написать свою (в транзакции работает довольно быстро)
Переходи на SQL там такого понятия нет ..)
Это обусловлено механизмом хранения остатков, но .... что есть то есть , эт наверное таки да неудобно , но приходится чем-о жертвовать, ради увеличения скорости обращения к остаткам.
Интерфейс - это дело привычки...
Я пользуюсь одной единственно компонентой для устранения этих всех недосатков 1CPP.dll ( в народе 1С++)
а при ресайзе форм все работает нормально
почему такой вывод ?
Не нарвится , пиши прямые запросы на tSQL (опять же на 1CPP) работает на порядок быстрее...
Администрирование -> Тестирование и исправление ИБ -> Упаковка таблиц
Не соглшусь , но можно поспорить ...
Вопрос . При этом должен ли списываться товар со склада или не ?
А собссно что мешает кассиру выбрать клиента , завести сумму . и просто нажать на кнопку "Провести" ? Или найти документ этого плательщика, на его основании провести ПКО , причем чтобы сумма бралась имнно из Накладной... зачем что-то перепроверять ? оно уже забито поидее в справочнике ... а сумму можно ваще запретить редатировать , а брать ее всегда из накладной , не вижу никаких сложностей ... (хотя я и не вижу пока всей твоей задачи)
Я не спорю , есть такие задачи которые на 1С не решаются (например на 1С не написать фотошоп или старкрафт), для этих целей есть другие средства... Но что касается учета , на мой взглад это пока один из самых удачных механизмов , который бурно развивается (вышла же 1С v.8 , там наворотов побольше ... но и задачи решаются там уже не такого уровня как на 1С v.7.7)
Кратк. - сестр. тал. !
Спасибо, агромное за консультации. Я в принципе хотел это и услышать.
Просто есть желание строго отсеживать какие документы оплачены, какие нет. Т.е я хотел бы, чтоб была воможность АВТОМАТИЧЕСКОГО ФОРМИРОВАНИЯ табличной части Счёта-Фактуры, на основании нескольких неоплаченных РН, оплачивать которые будет одна организация.
Это не конфигурация "Торговля+Склад", я просто утрировал под понятия конфигурации "Торговли+Склад'а"
Задача в кратце такова:
АВИААГЕНСТВО.
1) Есть бланки строжайшей ответсвенности (БСО), которые даёт авиаагенству авиакомпании. При продаже авиабилетов тратится один, в исключительных ситуациях максимум 2 БСО. Т. е необходим учёт БСО (какие номера БСО были пущенны в ход, какие номера БСО были запоротые, какие номера БСО были взяты у авиакомпаний)
2) Формирование отчётов авиакомпаниям о продажах авиабилетов
3) Отчёт о взаиморасчётах с контрагентами и субагентами, отчёт о продажах для дира
Denn wo euer Schatz ist, da ist auch euer Herz
а какого уровня? например?
Denn wo euer Schatz ist, da ist auch euer Herz
Судя по описаниям 1С v.8 расчитана на средние , крупные и особо крупные бизнесс структуры
1C v.77, расчитана на сферу малого и среднего бизнеса ...
з.ы. с восмеркой пока еще не работал , хотя поставил ..)
Кратк. - сестр. тал. !
Если это все - тогда вроде ничего сложного ....
Навcкидку :
Два стправочника : Контрагенты , и субконтрагенты(подчиненный контрагентам, имеющий реквизить типа "контрагент")
т.е. можно будет просмотреть отчет как по вледльцу, так и по дочернему элементу.
Еще два справочника (или один)
БСО и номера БСО (подчиненный БСО, если у тебя только один вид БСО , тогда можно обойтись и одним)
документом "Продажа билета" увеличиваешь долг клиента , "банковской выпиской" погашаешь.
Причем "Продажу билета" для удобства можно формировать из справочника "Контрагенты" (передавать из справочника в документ текущий элемент шоб автоматом заполнялись все поля ).
БСО у тебя расходуется при продаже билета ? если "да", тогда в документе "Продажа билета", необходимо держать реквизит с типом "документа БСО" , и списывать его соответтвенно при проведении документа "Продажа Билета".
Нужно содать два регистра , один по учету БСО , другой по взаиморасчетом с контрагентам ....
(хотя а бы наверное сделе бы учет БСО на справочниках , а не на регистре)
ну вощем дето так ...
если задача не будет разрастаться в дальнейшем это гдето на неделю работы , плюс еще неделя (или две отладки)
Кратк. - сестр. тал. !
Да, у каждой авиакомпании свои БСО, своя нумерация, вернее 1-ые 3 цифириУчёт БСО тока в служебном справочнике, регистр в данном случае не нужен, так как накопления какаих либо сумм, чисел не производится
Разрастаться будет и будет....
Denn wo euer Schatz ist, da ist auch euer Herz
т.е. ты в самом начале большого пути ? ..)
Кратк. - сестр. тал. !
))))) Потом, если будет всё ок, портирую всю эту лабуду на Delphi+MySQL
Denn wo euer Schatz ist, da ist auch euer Herz
..)
ИМХО лучше уж сразу писать под MySQL, потому что потом будет влом переносить ....
Кратк. - сестр. тал. !
Ваши права
Ответить с цитированием
Социальные закладки