Путевые заметки...

12.05.08

Задачи пользователя - Адаптация типовых решений

Облегчаем жизнь по восстановлению ГП...
Значит, так... Типовая ТиС. Регистры Резервы, Заявки, Заказы, ЗаявкиЗаказы - отнесены (мною!) к "оперативным", т.е. значения которых имеют смысл (интересуют пользователя) только НА ТЕКУЩИЙ МОМЕНТ. Что было вчера/позавчера - нам до фени... При ___перепроведении___, допустим, реализации задним числом из проведения полностью исключаются любые манипуляции с упомянутыми регистрами. В проведении реализации фигурируют только остатки ТМЦ. При необходимости резервы/заяки/заказы правятся только текущим числом корректировочными записями. Все... Работает нормуль...


имеет отношение к данному топику:
//infostart.ru/profile/174/blogs/258/ - как меня достали неснимающиеся резервы
//infostart.ru/profile/174/blogs/234/ - медленные базы и прочая...

Добавлено 18/05/2008, пока идет восстановление ГП по описанной выше "технологии"... Приведу код модуля Документ.Реализация:

//ДОБАВЛЕНО НЕТИПОВОЕ
////Удаление движений по регистрам.
//Для Номер = 1 По Метаданные.Регистр() Цикл
// ОчиститьДвижения("Регистр."+Метаданные.Регистр(Номер).Идентификатор);
//КонецЦикла;

_фАктуальноеПроведение = ИтогиАктуальны();
Если _фАктуальноеПроведение = 1
Тогда _фАктуальноеПроведение = 1 - Проведен();
КонецЕсли;

Если _фАктуальноеПроведение = 0 Тогда
//здесь идет проведение задним числом
//в заднем числе нас интересуют только:
//остаткиТМЦ, ПартииНаличие, Взаиморасчеты, Продажи, РеализованныйТовар
//все остальное - не трогаем...
//Удаление движений по регистрам.
Для Номер = 1 По Метаданные.Регистр() Цикл
ИдРегистр = Метаданные.Регистр(Номер).Идентификатор;
Если Найти("РЕЗЕРВЫТМЦ‡ЗАЯВКИ‡ЗАКАЗЫ‡ЗАКАЗЫЗАЯВКИ",ВРег(ИдРегистр))<> 0
Тогда Продолжить;
КонецЕсли;
ОчиститьДвижения("Регистр."+ИдРегистр);
КонецЦикла;
Иначе
//Удаление движений по регистрам.
Для Номер = 1 По Метаданные.Регистр() Цикл
ОчиститьДвижения("Регистр."+Метаданные.Регистр(Номер).Идентификатор);
КонецЦикла;
КонецЕсли;
//КОНЕЦ ДОБАВЛЕНО НЕТИПОВОЕ 


//соответственно, далее по алгоритму проведения обходится расчет остатков с учетом резервов/завок...

...можно критиковать....


обсуждение по данному вопросу можно почитать и вот тут
http://www.kuban.ru/forum_new/forum9/files/311174.html

См. также

Улучшенная обработка "Внешние печатные формы" для типовых конфигураций на базе 1С 7.7

Печатные формы Адаптация типовых решений Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Приятное улучшение обработки "Внешние печатные формы" для типовых конфигураций на базе 1С 7.7 для более комфортной работы с "любимой семерочкой".

1 стартмани

04.02.2022    3200    1    igor7777    0    

3

Расчет страховых взносов в 1С 7.7 "Учет и отчетность предпринимателя, ред. 1.2" с апреля 2020

Адаптация типовых решений Платформа 1С v7.7 Конфигурации 1cv7 Россия Бухгалтерский учет ФОМС, ЕФС Бесплатно (free)

В этой статье описано, какие небольшие изменения можно внести в модуль документа Начисление налогов с ФОТ, чтобы правильно рассчитывались страховые взносы с 1 апреля 2020 г.

09.04.2020    19676    Юджин58    39    

5

Дистрибьюция 7.7. Часть 1. Жизненный цикл заявки покупателя. Одна заявка покупателя, много адресов доставки.

Адаптация типовых решений Платформа 1С v7.7 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Управленческий учет Бесплатно (free)

Описан способ работы с учетом расписания с приоритетными покупателями - торговыми сетями (основными покупателями) в торговой или комплексной учетной системе на 1С 7.7. Множественная заявка покупателя на несколько торговых точек.

14.10.2019    6009    ksnik    14    

3

Как в торговле 7.7 печатать код ТНВЭД в счет-фактуре

Операции по ВЭД Адаптация типовых решений Оперативный учет 7.7 1С:Торговля и склад 7.7 Россия Бухгалтерский учет НДС Бесплатно (free)

В данной статье хотел поделиться опытом, как в Торговле 7.7 ( релиз 994) сделать возможность выводить код ТНВЭД в печатную форму счета-фактуры. Сразу скажу, что нужно это только тем, кто осуществляет экспорт в страны таможенного союза. Остальные могут не волноваться.

15.11.2017    11816    AndKovalchuk    0    

1

Предельные базы взносов в ПФР, ФСС, ФФОМС 2015 в 1С: Бухгалтерия 7.7

Зарплата Адаптация типовых решений Бухгалтерский учет 7.7 1С:Бухгалтерия 7.7 Россия Бухгалтерский учет Абонемент ($m)

Реализация Постановления Правительства РФ 1316 от 04.12.14 для типовой конфигурации "Бухгалтерский учет 7.7" рел. 7.70.590

1 стартмани

31.12.2014    23928    9    Sergey1CSpb    2    

0
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. poppy 12.05.08 23:02 Сейчас в теме
Почему бы не отнести к "оперативным" все остальные регистры? И при перепроведении исключить манипуляции в т.ч. и с остальными регистрами?
2. CheBurator 3119 12.05.08 23:32 Сейчас в теме
... Потомушта нельзя быть красивой такой ...
Если кратко (имхо глубокое):
1. история остатков/взаиморасчетов/авансов/прочего - имеем значение для бухии и/или УУ;
2. можно уйти от ГП, но получится "неуниверсальный" механизм, достаточно трудоемкий и неочевидный для юзера (непривычный).. чтобы сделать его "привычным" - забодаешься...
5. poppy 13.05.08 00:22 Сейчас в теме
(2) по п.2

Посмотри решения от hogik'a. Он отказался от ГП, создал математику и реализовал альтернативный движок.

У него все регистры - "оперативные", но у тебя = не рыба, не мясо
7. CheBurator 3119 13.05.08 00:40 Сейчас в теме
(5) > Посмотри решения от hogik'a.
...ссылка?
11. poppy 13.05.08 00:50 Сейчас в теме
13. CheBurator 3119 13.05.08 01:00 Сейчас в теме
(11) в обсуждении коментов Ходжик сказал "Остатки сходятся" (Есть остатки (итоги) на реальных полках.) - это да, вопросов нет если это только торговля... для бухии важны "виртуальные" вчерашние кошельки/полки - что выгоднее - каждый раз тащить данные отчетом или вытаскивать из регисторв - хз... тем более, что схема хранения данных, описанная Ходжиком, "близка" к системе регистров остатков 1Сины (на беглый взгляд).
3. hogik 443 13.05.08 00:09 Сейчас в теме
Если говорить о типовой ТиС – полностью согласен. А если говорить в целом, то при проектировании схемы базы данных надо соблюдать простое правило – вычислять надо только те значения, которые нужны НА ТЕКУЩИЙ МОМЕНТ. А те, которые требуются один раз в месяц – вычислять как рабочую величину именно один раз в месяц. И делать это в выходных формах, а не в “регистрах длительного хранения”.
4. CheBurator 3119 13.05.08 00:16 Сейчас в теме
(3) ГП - универсальная штуковина и катит везде. Все прочее - придется "специализировать", как пример, например лекарства - там, например, списываемую себестоимость в конце месяца не посчитаешь... + для оперативного управления, например, ВСЕ ВРЕМЯ вычислять раскладку "себестоимости" может быть накладно, и проще держать ее по факту возникновения в регистрах... - итого: вываливаемся в специализированные нетиражируемые решения...
+ мысль следующая: добавив в регистр измерение "документ" можно писать для этого "документа" движения в любой момент, а не только самим "документом" - тут надо подумать... идея, имхо, перспективная...
9. hogik 443 13.05.08 00:49 Сейчас в теме
(4)( Сhe Burashka)
Если типовую ТиС не переделывать полностью под конечного пользователя (продавца, кладовщика, мастера производства и т.д.), а считать конечным пользователем бухгалтера то, действительно, получится “не рыба, не мясо”.
(5)(poppy)
И у нас проблем навалом. Иногда, я очень жалею, что я затеял эту полную переделку конфигурации. Думаю, мы “перегнули палку в другую сторону”. Система работает в режиме 24х7 уже восемь лет. Но, с каждым годом всё труднее и труднее учитывать новые пожелания пользователей. Потеряна гибкость, универсальность и “заменимость разработчика”… ;-(
(6)(poppy)
“"оперативные" регистры потеряют свою актуальность”
Не потеряют – они же в апострофах. Как пример. Регистров “Резервов и ЗаявокЗаказов” не существует. Это реализуется простым перемещением на “склад резервов и заказов”. ;-)
(7)(Сhe Burashka)
Ссылки нет. Могу только пригласить Вас к себе в гости.

12. CheBurator 3119 13.05.08 00:51 Сейчас в теме
(9) В гости - это интересно... Тем более, что Владимир от Москвы недалеко.. Надо подумать над этим... было бы интересно поговорить, опытом поменяться... правда я сомневаюсь, что я что-то интересное смогу выдать...
14. poppy 13.05.08 01:02 Сейчас в теме
(12)
> Тем более, что Владимир от Москвы недалеко..

Может я неправльно поняла, но Владимир в Москве?

Я бы тоже в гости не отказалась... ;-) Хотя, также, выдать что-то вряд-ли интересное.
15. hogik 443 13.05.08 01:08 Сейчас в теме
(14)(Сhe Burashka)
“я что-то интересное смогу выдать”
Это и не требуется ;-) Я очень внимательно слежу за Вашими публикациями на данном сайте. А вот, сколько потребуется “сидеть” около нашей разработки – это вопрос. А типа, видео ролика от Олега по “Кассирочке” маловато будет. Кстати мы не во Владимире, а в 15-20 километрах от МКАДа.
20. CheBurator 3119 13.05.08 01:15 Сейчас в теме
(15) так что наклевывается поездка к Ходжику - если недалеко от МКАД... (по вопросам совместного заседания - спишемся в привате)
32. hogik 443 13.05.08 02:08 Сейчас в теме
(20)(Сhe Burashka)
Кстати. Списаться в привате, средствами данного сайта, для меня проблематично – мозгов моих на это не хватает. Решил сегодня написать сообщение и обнаружил, что мне там куча писем пришла. В старой версии сайта мне приходили сообщения на реальную почту о том, что поступило сообщение в приват данного сайта. А теперь не приходят. И я не понимаю, как посмотреть свежие сообщения.
34. CheBurator 3119 13.05.08 02:17 Сейчас в теме
(32) мой мыло для контакта: e.meil@mail.ru
6. poppy 13.05.08 00:34 Сейчас в теме
Изменение остатков задним числом без изменения Резервов и ЗаявокЗаказов = бяка.

Несложные манипуляции "задним числом" с остатками приведут к тому, что "оперативные" регистры потеряют свою актуальность и перестанут отражать действительную реальность.
8. CheBurator 3119 13.05.08 00:46 Сейчас в теме
> Несложные манипуляции "задним числом" с остатками приведут к тому, что "оперативные" регистры потеряют свою актуальность и перестанут отражать действительную реальность.
...а вот и нихренюшеньки! как раз наоборот!!! На текущий момент мои "оперативные" регистры будут отражать текущее состояние дел, ПРИЧЕМ С УЧЕТОМ ТОГО, ЧТО ПРОИЗОШЛИ ИЗМЕНЕНИЯ ОСТАТКОВ ЗАДНИМ ЧИСЛОМ. Что может быть:
- остатков стало на ТА больше - ничего страшного не произойдет, ситуация НЕ УХУДШИТСЯ.
- остатков на ТА стало МЕНЬШЕ - в худшем случае не сможем обеспечить требуемое кол-во резервов/заявок/заказов - ну так это и есть правда на ТА - часть из них скушана "взади"...
10. CheBurator 3119 13.05.08 00:49 Сейчас в теме
попутно еще одна фишка озвучу (я ее уже подымал) - достаточно интересно подумать над системой автораспределения поступления ТМЦ под необходимые заявки/резервы, КОГДА НЕХВАТКА НЕОБХОДИМОГО КОЛ-ВО ТОВАРА СТАВИТСЯ "В ОЧЕРЕДЬ" К ПОСТУПЛЕНИЮ ПРОСТЫМ ВЫВЕДЕНИЕМ РЕЗЕРВИРОВАНИЯ "В МИНУС" ... - тут думать...
16. O-Planet 6431 13.05.08 01:08 Сейчас в теме
Смелое и новаторское. Это усегда гут. А если еще и работает, то вообще! Впрочем, важна идея прежде всего.
17. CheBurator 3119 13.05.08 01:08 Сейчас в теме
Введение оси времени, сделанное 1Синой, порождает целую кучу казусов, которыми люди пытаются "потыкать в грязь лицом (ласково)", типичный пример (оттуда же):
..
разберем простейшую ситуацию:
1) введен приходный документ - 5 пар кирзовых сапог
2) зарезервировали 4 пары для клиента
3) обнаружили пересорт - 3 пары сапог и 2 пары тапочек, исправили задним числом приходник
4) вопрос - достоверен ли резерв? в каком состоянии будут остатки после продажи?
как отрабатывается данная ситуация?
..
При этом забывается, что несмотря что ось времени есть - МАШИНЫ ВРЕМЕНИ НЕТ. И если обнаружен пересорт, то В ОБЩЕМ СЛУЧАЕ выход только один: ТЕКУЩИМ ВРЕМЕНЕМ "скорректировать" ТЕКУЩИЕ ОСТАТКИ и "СКОРРЕКТИРОВАТЬ" РЕЗЕРВЫ и ПРОЧИЕ "ОБЯЗАТЕЛЬСТВА" !!!___ПО ФАКТУ ОБНАРУЖЕНИЯ НЕСТЫКОВКИ___!!! ВСЕ!!! иначе - не бывает.
ИНАЧЕ - только полная перерисовка всей АМБАРНОЙ КНИГИ с самого момента РЕГИСТРАЦИИ "НЕПРАВИЛЬНОЙ" записи. - а ведь амбарная книга-то прошита, пропечатана, и пронумерована на каждой странице. ВСЕ! ППЦ! никаких задним числом правок. Любая правка задним числом - иди на поклон к барину и проси разрешения...
18. CheBurator 3119 13.05.08 01:12 Сейчас в теме
> Иногда, я очень жалею, что я затеял эту полную
переделку конфигурации (фраза от Ходжика)
.. вот!!! мой мелкий опыт показывает - очень во многих случаях (для ТОРГОВЫХ компаний) можно добиться работы только в ТА и в типовой ТиС - это требует в первую очередь дисциплины документооборота и выполнения обязательств поставщиков/покупателей. Примерное время приведения "бардака" в "порядок" - от полугода до года.
26. hogik 443 13.05.08 01:26 Сейчас в теме
(18)( Сhe Burashka)
“можно добиться работы только в ТА”
У нас это не получилось – пришлось отказаться вообще от этого, на мой взгляд, странного понятия. Организация, то у нас (по количеству пользователей) не мелкая – уже около 75 рабочих мест. И все в 1Су норовят войти…
(19)(O-Planet)
“свою писать по накопленному опыту”
Ох. Сейчас, думаю, что и не надо. Нашу систему писали 1,5 человек, и всё пишем -пишем…

27. CheBurator 3119 13.05.08 01:34 Сейчас в теме
(26) на мой взгляд, работа в ТА как раз не странное понятие - как раз и есть та самая "реальная полочка", про которой ниже по ссылке обсуждались комменты.
... ясен пень, раздолбайство (в организации), ничем не лечиться... можно сгладить симпотомы, но плата за это - сидим "на игле" "нетипичной пневмонии"...
29. hogik 443 13.05.08 01:49 Сейчас в теме
(27)(Сhe Burashka)
Про ТА можно долго говорить. Но самое лаконичное Ваше –“что несмотря что ось времени есть - МАШИНЫ ВРЕМЕНИ НЕТ”.
“плата за это - сидим "на игле" "нетипичной пневмонии"...”
Вот мы и платим. А если зарабатывать деньги заказами, то наше решение никуда не годиться. Так, – частное решение, хотя и работает в конкретной организации совсем не плохо.
44. tango 506 02.06.08 11:02 Сейчас в теме
(18)+(19) поясню согласие с обоими.
Либо ТиС, либо своя с нуля самописка по хотелкам.
Корежить типовую - самое гиблое дело. Для студентов.
45. CheBurator 3119 02.06.08 12:26 Сейчас в теме
(44) Тут я не совсем согласен. Типовая ТиС вполне работоспособна в большинстве организаций в основном своем функционале (вот она выгода универсализма), грамотная "доточка" и скрытие ненужных/неиспользуемых возможностей - экономит кучу времени по написанию "нетленок"... Как раз хуже всего когда "студент" начинает корежить типовую под запросы клиентов, при этом очень слабо представляет собе логику и возможности типовой - не только в плане технической реализации, но и в плане МЕТОДИКИ применения... Для "штатных" ситуаций клиентов чаще всего приходится "подтачивать" взаиморасчеты в разрезе поставок/продаж... все остальное - если понадобилось, то, как правило, на фирме уже есть свой прог... (другое дело если прог - "вещь в себе" - вероятность того, что решения будут "кривые" - очень высока). На примере старой работы: (опт лекарства) - все доточки были сделаны на 95% внешними отчетами/обработками + минимум изменений в ключевых точках (по возможности с вызовом внешних обработок), в результате если студент "накатит" типовое обновление "не глядя" - такие клоуны встречаются - прога будет по-прежнему работоспособна с потерей некоего функционала...
19. O-Planet 6431 13.05.08 01:13 Сейчас в теме
Но по-моему, надо не типовую терзать, а давно пора свою писать по накопленному опыту и выставлять, как альтернативную. Кстати, можно у суппорта перекупить название "Апельсин", ведь оно к чебурашкам как раз напрямую относится. ;)
21. CheBurator 3119 13.05.08 01:16 Сейчас в теме
(19) Главное, чтоб гвоздей вместе с апельсинами не было... ;-)
22. CheBurator 3119 13.05.08 01:17 Сейчас в теме
Писать альтернативную конфигу - можно попробовать, но совсем простенькую, типа количественного учета "для ларька"...
23. CheBurator 3119 13.05.08 01:20 Сейчас в теме
> Но по-моему, надо не типовую терзать, а давно пора свою писать по накопленному опыту и выставлять, как альтернативную.
..неоднократная проработка этого вопроса на разных клиентах, которым "мне вот совсем ничего надо - совсем простой учет нужен", показывает что клиенту возможно понадобится и вот это, и вот это, а! да! это точно надо, я совсем забыл... и т.д. - в итоге практически весь функционал типовой ТиС... так что если ставить вопрос широко (на размах моих ух) - то надо сделать "вторую типовую ТИС" с "человеческим лицом" - а на это, боюсь, силенок у нас не хватит...
24. CheBurator 3119 13.05.08 01:24 Сейчас в теме
...по хорошему что надо - в типовой ТиС четко по блокам разнести движения денег и движения ТМЦ, в т.ч. разнести это по разным последовательностям.
... и ВООБЩЕ! ГЛУБОКОЕ ИМХО: следующий рывок имеет смысл делать в более явной блочности построения типовых конфиг (пусть даже в ущерб производительности)...
25. CheBurator 3119 13.05.08 01:26 Сейчас в теме
...все куда-то срулили... я не Сруль, я - Чебурашка... пойду повтыкаю в экстремальное кино (посудить на Питерский фест надо) и спать через часок...
28. O-Planet 6431 13.05.08 01:45 Сейчас в теме
Если говорить о программе для торгового концерна с кучей филиалов, то свою писать не надо. Я сталкиваюсь часто с средними и мелкими фирмочками, которые 70% ТиС не используют, но вынуждены отрабатывать (разные проекты, основные свойства и т.д.) По-нормальному, нужна махонькая прога для торг. организации с нормальным партионником, с приятным интерефейсом и с защитой от ввода задним числом (чтобы оно - излюбленная операция юзеров, поддерживалось, но все не портило). В ТиС есть предпосылки богатой аналитики, но иногда элементарное оказывается не реализовано. Пример - отчет по продажам ТМЦ. Узнать бы, кто придумал туда вместо склада МОЛ вставить! Самое прикольное, что этот МОЛ у всех либо проигнорирован, либо один. А потом просят: покажите продажи в разрезе магазинов. Приходится доки иногда за год перепроводить.
30. CheBurator 3119 13.05.08 01:53 Сейчас в теме
(28) Продажи в разрезе магазинов: юрлицо - одно, несколько фирм, каждая фирма = магазин.
31. poppy 13.05.08 02:02 Сейчас в теме
(28)
> Я сталкиваюсь часто с средними и мелкими фирмочками, которые 70% ТиС
> не используют, но вынуждены отрабатывать (разные проекты, основные
> свойства и т.д.)

Они что, мазохисты? ТиС нормально без проектов и основных свойств работает...

33. CheBurator 3119 13.05.08 02:16 Сейчас в теме
(31) Проекты - это любимое средство многих! вот вам ище одна идея, которая существенно облегчит жизнь.
- должноа быть возможность на любой док повесить любое количество маркеров-тегов (с предопределенными/любыми) значениями... ряд проблем/задач решался бы на раз (типовая задача: отметить и взять "на контроль" некоторые документы) - т.е. аналог свойств для документов (по образу свойств для справочников...) - И ТАКАЯ ПАРАДИГМА БУДЕТ БЛИЗКА ДЛЯ МАНАГЕРОВ!
37. poppy 13.05.08 12:13 Сейчас в теме
(33)
В восьмерочных конфигурациях это уже реализовано. Там документам можно назначить и свойства, и категории.
38. CheBurator 3119 13.05.08 21:42 Сейчас в теме
35. CheBurator 3119 13.05.08 02:18 Сейчас в теме
nm[e на вас всех газировкой с сиропом (апельсиновым), отключаюсь... в выходные выходите на связь!!!! тогда можно продуктивно пообщаться!
36. O-Planet 6431 13.05.08 02:39 Сейчас в теме
>> - должноа быть возможность на любой док повесить любое количество маркеров-тегов (с предопределенными/любыми) значениями...
Идея эта не нова. Я такое сделал в одной фирме, только "навешиваю" на доки статьи расходов для внутреннего учета. И у мну в Документообороте они тоже есть, но ты говоришь сейчас о более общем. А вообще, маркеры на доки пора бы уже кому-то запатентовать... ;)
39. Kurt 110 14.05.08 11:37 Сейчас в теме
Значит всего-то и осталось восьмёрочную конфигурацию "переписать" под семерку.... шучу.
40. hogik 443 01.06.08 17:56 Сейчас в теме
Начал изучать 1С 8.х и опять, как и при изучении 1С 7.7, задумался над фразами:
“Факт проведения документа и необходимость поддержания актуальной последовательности документов на оси событий порождают…”
“…отметка времени создается системой каждый раз при … проведении документа”
Т.е. “ось событий” отражает работу оператора по вводу документа. Мне в торговле известен только один документ, где событие набивки документа соответствует реальной жизни – это чек ККМ. В остальных документах нет единого события, по которому можно построить ось событий и сопоставить ее с действиями операторов по набивки документов. Точнее, этих событий множество - дата первичного документа, дата отгрузки, дата прихода на склад, дата списания остатков (реально отгрузки), дата разрешения отгрузки и т.д. Но все эти даты не имеют никакого отношения к работе оператора и компьютера. Тогда зачем ЭТО?
41. CheBurator 3119 02.06.08 08:49 Сейчас в теме
(40) УТ, как и ТиС в 7.7, к _процессу_ торговли имеет весьма отдаленное отношение...
42. vip 02.06.08 09:30 Сейчас в теме
43. CheBurator 3119 02.06.08 10:09 Сейчас в теме
(42) НО! это - плата за универсальность (в какой-то мере).
Явно не секрет, что есть куча решений, разработанных и поддерживаемых в конторах фиксями/фрями (наверняка с кучей интересных/оригинальных решений/находок) - но в "массовом производстве" - их не видно...
46. hogik 443 02.06.08 17:06 Сейчас в теме
(40)
“УТ, как и ТиС в 7.7, к _процессу_ торговли имеет весьма отдаленное отношение...”
Это я понимаю ;-) Но и на других участках АСУ-па существует понятие первичный документ. Существует, для некоторых документов, “необходимая” хронология их обработки. Но на коробке продукта 1С: Предприятие написано “Сетевая”. Я это понимаю как – “многопользовательская”. И документы в систему могут поступать в произвольном порядке – ну, например, разделили операторы пачку документов между собой. И при вводе документов компьютерная “ось событий” теряет всякий смысл. Т.е. после ввода документов их надо в “монопольном” режиме расставить на ось. Но если критична последовательность операций, то это достигается другим способом. Например, если критично продавать конкретный товар конкретной накладной, то это партионный учет c ручным выбором партии в расходном документе. И какое это имеет отношение к взаимному расположению приходной и расходной накладной по компьютерной дате и времени? Т.е. средства обеспечения последовательности операций должна базироваться на самой сути этих операций. Или я чего-то не так понимаю?
Оставьте свое сообщение