Такое дело. Вполне естественно, что руководство хочет, чтобы учет в инфобазе работал идеально. Очень важна корректность расчета себестоимости, партионного учета и т.д. Движений товара много: поступления, реализации, списания, перемещения и т.д. между большим количеством складов (относительно большим - около 20). При этом иногда сотрудники (пользователи инфобазы) по согласованию с руководством формируют временные документы, например временные продажи какого-нибудь товара. После по этому товару с этого склада (с которого были сделаны временные реализации) создаются еще движения. Спустя некоторое время, например 10-20 дней просят эти временные реализации - отменить или удалить. Это только один из моментов. Объяснения о том - как это повлияет на учет - никому не интересно, при этом нужно обеспечить правильный учет. Как вы поступаете в таких ситуациях или я чего-то не понимаю?

(38) ничего подобного, более того моё взаимодействие с теми самыми сотрудниками ограничивается перепиской в электронной почте. все задания получают от вышестоящего руководства

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

Круто... Временная продажа, временная оплата.  А потом заплатить временные налоги. Причем платеж по налогам тоже будет временный.

(36) исправлять косяки должен тот кто их сделал и желательно раньше, чем будет закрытие месяца

(39) я вот недавно общался с фин. диром другой конторы, которая мне рассказывала, если бухгалтер или финансист не знает как оформить ту или иную операцию (не только в 1С), а вообще, то программист должен рассказать как это сделать, так же именно программист должен находить и исправлять все косяки пользователей

(43) а потом срок временный за временную неуплату временного налога временно начисленного

(41) Ты руководству объяснял ситуацию, что сотрудники не верно отражают операции?

(36)
>> а исправлять косяки кто должен?

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

(43) (46) я уже написал что понималось под временной продажей - это заказ покупателя в процессе согласования

(45) Так если не знает, пусть спрашивает. Тебя же не спросили, когда сделали "временную" продажу?

(41) ну хоть в чем-то у Вас там порядок :-)

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

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

НО!!! Ни в коем случае программист НЕ ДОЛЖЕН вносить исправления данные, как минимум, он не может этого делать без получения санкции на КАЖДОЕ вмещательство в работу Пользователей.

(50) не спросили, это я на вопрос о том, чем должен заниматься одинэсник

(49) чем им заказ покупателя не нравится?

(53) я уже написал, они просто не знали как сделать правильно и сделали так как сами придумали

(49) Пусть делают заказ. Если нужен статус заказа (согласован, не согласован) - возможно потребуется доработка.

(53) да тупые просто
иногда такое встречается

(51) +++
Программист отвечает за корректность работы программы (при условии работы с программой согласно правилам, инструкциям). За ввод данных отвечают пользователи и исправлять введенные данные будет нормальным если эти данные получились из-за программной ошибки. А если из-за "а мы вот так решили это делать и теперь за нами вычистит тут" - то ну их нафиг

(54) выдай инструкции, проведи обучение, обещай покарать за отступление от инструкций, всем новым сотрудникам давай ознакомиться

(58) карательными полномочиями я увы не наделен

(59) выйди на их начальника

(60) или скажи своему начальнику поговорить с их начальником, если у вас так принято

(45)
>> рограммист должен рассказать как это сделать

Не верь финансовым директорам. Особенно ушлым тетям - бывшим ГБ.

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

(62)
>> так же именно программист должен находить и исправлять все косяки пользователей

Не то процитировал. Не должен.

(63) а если у нас общий начальник и именно он руководит всем этим процессом - дает добро пользователям совершить ошибку, а мне её исправить?

(64) а я думаю, что на самом деле очень многие лезут в учет и правят за пользователями, даже знаю, что так делают

Да и еще по оглавлению Топика
// Как обеспечить правильный учет, если в базе есть "временные продажи"? //

Правильный учет обеспечивают Пользователи.
Программист обеспечивает бесперебойную работу программы или комплекса программ.

(65) тогда ты будешь по 14 часов в сутки править пользовательский бред, беги оттуда!

понял, что всеобщее мнение - это бежать)

(45) > программист должен находить и исправлять все косяки пользователей

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

> все задания получают от вышестоящего руководства

И опять верно!

Вывод? А вывод простой! Ты знаешь о косяках пользователей (руководство, которое отдаёт команды оформлять через *опу данные - это тоже между прочим пользователи).
Ты официально(!) пишешь письмо руководству, которое поставило тебе задачу о том что:
1. Принятая методология с т.н. временными реализациями не соответствует реализованной в программе методике ведения учета.
2. Возможности автоматизировать эту ересь в рамках здравой логики и за разумные сроки нет.
И выдвинуть предложение, содержащее верный метод стоящей перед ними задачи (учёт заказов). Где описать - какими документами, кто и как должен вносить информацию.

В этом (последнем) пункте и будет содержаться решение той задачи, которую поставило перед тобой руководство.

А тот бред, который ты несёшь, про то, что надо бегом бежать и что-то в конфигурации править под идиотизм менеджеров, - есть не что иное, как ложное понимание задачи, которое ставит руководство.

(69) Сначала попробуй объясни начальнику что то "временные продажи" это неправильно. Если не получится, то да, бежать

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

Я однажды говорю своему Начальнику : если наши Пользователи не успевают или не умеют или делают что-то неправильно по каким-то причинам, ну давайте Я сделаю это сам?

Начальник ответил: услуги программистов для нас будут иметь слишком дорогие последствия, если вместо Пользователи в программе будут работать Программист.

Поэтому я от своего Начальника еще никуда не убежал.

а в чем проблема отменить реализации? ну отменили и отменили

(70) всякие галочки в настройках - тоже пользователи вносят. сам ни-ни?

(73) вообще не проблема! Распускаем отдел продаж и набираем в отдел программистов менеджеров по продажам.

(75) почему бы пользователям не дать возможность самим удалять?

вон в ерп вообще есть статусы

(76) Он им все дал, объяснил, рассказал. А они ссылаются на какого-то начальника и говорят: холоп, быстро поправил все тут! НЕ барское это дело - мы тут накосячили, понимашь, так еще и исправлять чтоли сами должны?!

(74) >  всякие галочки в настройках - тоже пользователи вносят. сам ни-ни?

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

Исключения составляют какие-то чисто административные моменты, не касающиеся самих данных.

(79) ты скажи что и в консолидации пользователи сами себе отчеты рисуют

Какой-то чернухой попахивает...
а реально товар уходит и возвращается? или это некая "виртуальная реальность"?

Или часть этих "временных" продаж превращается в реальные?

еще один момент, продажники сделали эту продажу, распечатали документы, пустили товар налево, приходит налоговая со встречной проверкой, а в базе документов нет. А продажники не при делах, говорят, что не знают что такое, это программист документы удалил все.

(0) Бардак. Программистом такое не решается, только на уровне руководства. Либо достучаться до руководства, либо расслабиться и забить, либо валить.

(82) в базе ты можешь херачить, что хочешь, налоговой до этого дела нет.

(80) А чем консолидация отличается от других систем?
На этапе настройки обменов данными, формирования правил загрузки из других систем, могут привлекаться консультанты, которые по указаниям пользователя настраивают систему.
То есть пользователь на пальцах рассказывает что, откуда и куда должно прилететь, а консультант эти хотелки реализует.
Если на уровне настроек задача не решается - привлекается программист.
Но ни программист, ни консультант по собственной инициативе никакие данные и настройки не трогают. Это вне их компетенции. Любая настройка делается либо самим пользователем (консультант и программист только подсказывают, консультируют и рекомендуют), либо с его (пользователя) ведома, по согласованному на бумаге ТЗ.

(85) обычно программист и он же консультант

(85) у вас что никакой системы учета задач нет? все тз только на бумаге?

(84) ндсы всякие мы в электронном виде сдаем

(82) А при чём тут база данных? Органы работают с бумагой, а не с базами данных. Не говоря уже о том, что приведенный тобою пример равно можно реализовать в жизнь и при абсолютно правильно поставленном учёте. Для этого не нужно руко*обства описанного в (0).

(86) > обычно программист и он же консультант

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

(89) Ты с дубу рухнул. Сейчас декларация НДС занимает по 10 000 листов. С какой бумагой они работают? Туалетной?

(87) > у вас что никакой системы учета задач нет?

Конечно есть?

> все тз только на бумаге?

Нет. Все ТЗ в электроном виде.

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

(89)  в случае чего можно подставить программиста, но если он лезет руками и удаляет реализации, то 100%

(91) Ты никогда с налоговой проверкой не сталкивался?
Либо у тебя запросят бумажные документы (живые или заверенные копии), либо электронные (выгрузка установленной формы, которую ответственные лица подписывают ЭЦП).
Когда речь идёт о декларации - смотрят ту выгрузку, которую ты в налоговую отправил по каналам связи, и которая опять таки подписана ЭЦП.
На то, что там у тебя в базе данных всем глубоко на*рать.

(93) программист может от чужого имени все удалить.
а потом говорить - это не я. это ГБ/Дир

(9) может было уже, но -- почему не резерв? Кому нужна эта "временная реализация"?
Я работала в опте, 5 лет. Когда пришла там тоже такое было, отучила за месяц

(96) может серии нужны?

(95) И это о*уенная проблема 1С. Всякие там еретические SAPы постоянно тыкают в сторону 1С по поводу этой дыры безопасности, когда специалист, выполняющий административные функции, имеет полный доступ к данным и это никак не разделено.

(97) если так, то делали перемещение на склад, и товар реально перекладывался

(98) проблема не в платформе. а в том что в небольших конторах 1с - он царь и бог

(100) ага :))
"Это программа сделала"

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

(102) подделать письмо, где рассказываешь ГБ как удалять )))

(100) Ты так это говоришь как будто это нормально.
Это дикость. Поэтому 1С так и не любят - за подобную дичь и ларёчный подход. Причем ларёчный подход даже на крупных и серьезных проектах.

(104) подход не от платформы зависит, от РП с обеих сторон

(104) для небольших контор - это вполне нормально

(104) причем тут именно 1 С?

(107) Потому что в некоторых крупных системах типа SAP, на конкуренцию с которыми всерьез претендует 1С, таких проблем нет. Программист там не имеет доступа к реальным данным вообще. А администратор, накатывающий патчи, физически не имеет возможности корректировать данные - только конфигурацию (в терминах 1С).

(105) > подход не от платформы зависит, от РП с обеих сторон

Полностью согласен. Только, во-первых, правильный подход встречается крайне редко. А, во-вторых, даже при правильном подходе остаётся специалист, который делает обновления (устанавливает доработки, патчи и пр.) и осуществляет прочие административные функции и фактический имеет полные права на все данные. Что даёт ему возможность не только вмешиваться в данные, но и заметать следы вмешательства (чистить ЖР). С точки зрения безопасности это просто пи*дец.

(23) а разве в задачу программиста не входит - за всеми всё исправить\\\
тогда я программист )))

(108) ясно.

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

появился еще вопрос на счет обмена данными. выполняется обмен данными между базами, например из УТ в БП по расписанию - раз в неделю. но после обмена какие-то доки правятся, добавляются, удаляются в УТ, соответственно в БП все эти исправления тоже нужно зафиксировать. кто это должен делать - программист или пользователь (бухгалтер или менеджер)

(111)
// в штате пара тройка одинэсников, очень редко обходится,
// чтобы программист не лез в данные

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

(112) А каким образом сейчас завершается перенос данных из базы в базу? Вот полный цикл до появления корректировок, потом корректировок не было, потому что повезло, а потом корректировки приключились - не повезло.
Можно перечислить события, который возникают?

(112) Еще раз! Программист данные не изменяет.
В журнале регистрации не должно быть ни одной записи с событиями Изменение/Добавление/Удаление, где пользователь был бы - программист.

Исключение - обработчики обновления, которые запускаются после обновления конфигурации.

То, что ты описываешь - это косяки учёта. Либо необходимо избавляться от таких косяков. Либо (если избавиться невозможно в силу объективных причин) кто-то из пользователей должен сидеть и подобные косяки искать и править руками (довносить документы или корректировать). Роль программистов и консультантов в этой истории - рассказать пользователю как должно быть (как не делать косяки), как искать проблемы (что с чем сверять в разных базах) и как их правильно исправлять.

Ни программист ни консультант не обладают квалификацией, компетенцией и правом менять данные.
Нашел косяк - пишешь или звонишь пользователю: "У вас тут менеджер Вася накосячил и исправил документы в УТ задним числом - примите меры и исправьте документы в БП, пожалуйста". Ни один нормальный вменяемый главбух никогда не скажет тебе - "исправьте сами за Васю". Либо будет поставлена задача ответственному бухгалтеру - следить за такими проблемами и исправлять их, либо будут приняты административные меры к недопущению таких проблем.

Только так это работает. Только так косяков со временем станет меньше.

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

(115) абс. справедливо

(115)Ну еще выгрузка/загрузка данных тож бывает.

(114) правила обмена - типовые дописывались до нужно вида. средства для обмена используются типовые.
Но - обмен должен быть раз в неделю строго документов за эту неделю. Например выгрузились доки с 10.09 по 26.09.
В БП бухгалтерия эти доки у себя в базе обработали.
И на этой неделе в базе УТ какие-то доки исправляли или добавляли.
Бухгалтерия против обмена изменений за период с 10.09, так как прошло уже две недели. Просят добавленные или измененные документы догрузить отдельно (используем обработку Универсального обмена данными).

(119) те ты сам догружаешь? не они?

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

(121) это потому что инструмента нет нормального.
была бы обработка. где видно измненные, а они только нажимают ок ну или галочки там снимают, какие не выгружать

(112) Пользователям показали что надо нажимать для ручного выполнения обмена и они сами делают обмен, если им нужно "срочно".
Как уже много раз сказали: должно быть четкое разделение ответственности за ведение учета.
Программист 1С с высокой квалификацией может заменить большую часть сотрудников компании, т.к. по работе сталкивается с бухгалтерским учетом, налоговым, управленческим, кадровым и т.д., но это глупо и не рационально. При этом естественно, что конечные пользователи с радостью вешают часть своих функций на программистов.
Поэтому происходит постоянное перетягивание одеяла: мы заставляем пользователей делать свою работу, а они ищут все новые лазейки как спихнуть что-нибудь на программистов. Благо пока руководство на нашей стороне.
Понятно, что у новичка в профессии нет ни знаний, ни опыта, ни навыков для отстаивания своей позиции (а зачастую и морально-волевых качеств для отстаивания любых позиций, если это студент), но в любом случае к этому надо стремится. В противном случае не получится развиваться в профессиональном плане, т.к. рутина будет съедать все доступное время.
Если руководство действительно полностью неадекватно и нет никаких надежд на конструктивную совместную работу, то надо искать другое место работы.

(123) спасибо)

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

(33) https://cs6.pikabu.ru/post_img/2017/08/01/3/1501555390111535323.jpg

(121) > глав бух сказала что это должен делать программист

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

Что на это скажет главбух, интересно...
Может тогда до неё дойдёт, что программист ни за что не отвечает и по большому счёту может вообще сделать всё что угодно?

(122) > это потому что инструмента нет нормального.

+100. Бухгалтера понять можно. Когда ей показали универсальную обработку выгрузки-загрузки, где надо предварительно кучу хитромудрых галочек расставить и правильно все параметры выборки прописать, она и обо*ралась - тут ведь чёрт ногу сломит.

А по сути проблема решается либо каким-либо отчетом - о том какие объекты в (условно) закрытом две недели назад периоде повторно загрузились, либо какой-либо инструмент по загрузке таких данных более чем двухнедельной давности.

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

(18) Решается все тривиально - пользователь должен не иметь возможности делать неправильно. и не иметь возможности в оперативном процессе изменять сделанные операции/документы. и внезапно все проблемы исчезают.

(45) ну мне тоже почти такое рассказывали - я почти открытым текстом послал и сказал - не знают как - пусть берут счеты, журанл-ордер, главную книгу и пр и ведут я вручную - Я НЕ ВОЗРАЖАЮ. на этом все успешно закончилось.
правда у нас до сих пор нет того, кто отвечает за учет в торговой базе. По факту получаетяс так, что все делают свою работу и учет образуетяс сам собой. Взбрыки начинаются когда влазит бухия с какими-нить мутными хотелками.

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

(115) да, но тут засада. исправление косяков по ресурсам на порядок дороже самих косяков. вдобавок для исправления косяков часто надо понимать и знать как построен учет в (торговой) базе. не просто какие кнопки нажиамть (операционная деятельность). а какие неформализованные действия произвести по исправлению ВСЯКИХ проблем, чтобы получить правильный результат. таких людей в конторах - минимум или вообще нет (кроме п1с). Поэтому имхо один только выход - жесткая регламентация операционной деятельности.
в своей практике приходилось иногда доводить ситуацию до "ножей" (ввиду как раз отсутсвия такой жесткой регламентации некоторых участков операционной деятельности) по типу "если Маша еще раз сделает так как ей хочется, а не так как надо - я снимаю с себя обязанность за поддержание работоспособности базы. БУДЕТЕ ТРАХАТЬСЯ САМИ". только такая постановка срабатывала.

(121) пошли главбуха нафуй

(127) угу, именно. юзверям нужны инструменты для выполнения тупых действий. запустил обработку - нажал кнопку - удостовеорился ОК или НЕ ОК.
.
все.
понятно, что это треьует существенного участия програмимтиста в доработке проблемных участков. и тут уже как получится...

(124) // глав бух сказала что это должен делать программист

оно как бы ДА. Должен. Но он должен не загрузку/выгрузку исполнять, а ЗАПРОГРАММИРОВАТЬ всю эту обработку так, чтобы ответственный за свой участок учета бухгалтер или менеджер нажимал минимум кнопок, но ОТВЕТСТВЕННО и САМОСТОЯТЕЛЬНО передавал данные в БП и обратно.

Я периодически напоминаю юзерам, как это все работает. Но большую часть времени они справляются с этим сами, по готовым обработкам, но сами.

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

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

Анекдот в тему:
Знаете как выглядит Рай Бухгалтера?
В нем у каждого бухгалтера есть свой персональный программист!

(0) Вместо реализации достаточно делать Заказ клиента с резервированием на складе. Х..ней занимаетесь.

(137) :)) в другой теме сегодня уже было про каждой женщине по мужчине :) а если мужчина ещё и программист так больше ничего для счастья не надо

(138) да понятно это. описанное в (0) говорит лишь о том, что прога используется как печмаш и как инструмент для решения _сиюминутных проблем_ с потугами на какое-то подобие учета (они, пользователи и руководятелы этих пользователей как бы верять что такое возможно). а так как технической постановкой учета (бизнеспроцессов) в конторе никто не занимался, то такое как в (0) - сплошь и рядом.