Меню

Настройка нумерации кассовых ордеров

Во время проекта внедрения SAP ERP в России неизбежно возникает вопрос по подходу к нумерации кассовых ордеров. Стандартная функциональность SAP предоставляет несколько возможных подходов, каждый из которых имеет свои положительные и отрицательные особенности. В этой статье мы их рассмотрим.

1.      Введение

В настоящий момент порядок осуществления кассовых операций в РФ регламентируется следующими нормативными документами:

  • Письмо Банка России от 22.09.1993 N 40 "Порядок ведения кассовых операций в Российской Федерации"
  • Инструкция по заполнению регламентированных форм КО-1, КО-2.

В данных положениях указаны следующие требования к нумерации кассовых ордеров:

  • Нумерация должна быть непрерывной («Инструкция по заполнению регламентированных форм КО-1, КО-2» поле «Номер документа»).
  • Нумерация должна осуществляться в порядке возрастания с начала года (Письмо Банка России от 22.09.1993 N 40 "Порядок ведения кассовых операций в Российской Федерации" пункт 25).

Также в Письмо Банка России от 22.09.1993 N 40 "Порядок ведения кассовых операций в Российской Федерации" отмечается, что в случае ведения кассовой книге (учёта кассовых операций) с помощью программного обеспечения (в электронном виде), внешний вид кассовой книги может отличаться от регламентированной формы (машинограмма). Главное, чтобы в получаемой из программы печатной форме присутствовали все необходимые реквизиты.

Стандартные программы печати кассовых документов системы SAP ERP, позволяют вести нумерацию кассовых ордеров в следующих полях:

  • Поле “Номер документа кассовой книги для просмотра” (D_POSTING_NUMB) транзакции FBCJ
  • Поле “Ссылочный номер документа” (DOCUMENT_NUMBER) транзакции FBCJ

·      Поле “Номер документа” (BELNR) в FI-документе сформированном на основании документа кассовой книги.

2.      Предпосылки и ограничения использования данного решения

  1. Для учета кассовых операций используется транзакция FBCJ.
  2. Для формирования печатных форм КО-1/КО-2 используется программа J_3RFKORDR2_A.
  3. Для формирования печатных форм КО-3/КО-4 используется программа J_3RFCASH15.

3.      Описание решения

1.      Нумерация кассовых ордеров ведется в поле “Номер документа кассовой книги для просмотра”.

Такая возможность появилась, начиная с версии SAP ERP 6.0.

Такой способ предполагает настройку для кассовой книги групп нумерации, которые позволяют реализовать автоматическую нумерацию, а также независимую нумерацию ПКО и РКО.

Для использования этого способа нумерации требуется выполнить следующие настройки:

Определить группы нумерации, назначаемые кассовым книгам. Для одной кассовой книги создается 2 группы нумерации: одна для ПКО, одна для РКО

Рис.1 Путь к настройке групп нумерации

Рис.2 Форма настройки групп нумерации

Рис.3 Путь к настройке диапазонов номеров для групп нумерации

Рис.4 Настройка по созданию диапазона номеров для групп нумерации

Рис.5 Заполнение для кассовой книги диапазонов нумерации для ПКО и РКО

Достоинства:

  • Автоматическое раздельное формирование номеров ПКО, РКО средствами FBCJ.

Недостатки:

  • К сожалению, такое решение не позволяет сделать нумерацию кассовых ордеров непрерывной:
    • При предварительном сохранении кассового документа, система присваивает ему номер из диапазона, прикрепленного к группе нумерации. При этом при удалении этого документа, присвоенный ему номер не высвобождается и поэтому при сохранении следующего документа образуется разрыв в нумерации.
    • При создании документа сторно, система присваивает ему номер так же, как и обычному кассовому ордеру. А так как в отчете КО-3 система не показывает документы сторно, то образуется разрыв в нумерации.

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

2.      Нумерация кассовых ордеров ведется в поле «Ссылочный номер документа»

Ручное формирование номера кассового ордера в поле «Ссылочный номер документа».

При таком подходе номер кассового ордера формируется вручную и вводится в поле «Ссылочный номер документа» транзакции FBCJ.

Возможны следующие варианты организации бизнес-процесса по формированию кассовых ордеров с использованием предлагаемого способа нумерации:

  • Кассир работает вне SAP

Бухгалтер создает кассовые ордера и предварительно регистрирует их. В поле ссылка при этом он не вводит никакого номера. После этого бухгалтер распечатывает кассовый ордер и отдает его кассиру.

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

В конце дня кассир сдает бухгалтеру кассовые ордера. Бухгалтер вводит в SAP в поле “Ссылка” номера, которые кассир проставил в распечатанных кассовых ордерах и проводит их.

  • Кассир работает в SAP (номер присваивается при выдаче/получении денег).

Бухгалтер создает кассовые ордера и предварительно регистрирует их. В поле ссылка при этом он не вводит никакого

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев5

Комментарий от  

Олег Точенюк

  |  05 июля 2013, 01:32

Сложилось впечатление, что существует недопонимание, как работает генератор диапазонов номеров в SAP. В общем виде можно получить непрерывность номеров в системе, для этого надо чуток докрутить метод 3, но про это ниже.
 
1. Нумерация кассовых ордеров ведется в поле “Номер документа кассовой книги для просмотра” - Стандартное решение от SAP, ну кроме того что как было отмечено нельзя получить интервалы без разрыва, но и что более как мне кажется проблематично, это нельзя гарантировать постоянное увеличение номеров при нескольких серверах приложений, так как система произведет чтение номера из интервала, при этом каждый сервер приложение получит по номеру, далее если номер на каком-то из серверов использовался, система запросит следующий номер, но первый сервер приложения будет ждать своей очереди и может возникнуть ситуация когда нумерация будет выдана в таком порядке как 1<первый сервер>, 3<первый сервер>, 4<первый сервер>, 5<первый сервер>, 6<первый сервер>, 2<второй сервер>, 7<первый сервер>, что приводит пользователей в некоторое состояние задумчивости, особенно если номер 2 появится на следующий день.
 
2. Нумерация кассовых ордеров ведется в поле «Ссылочный номер документа» - Ну это уже какое-то ручное бессистемное извращение. На одном очень автомобильном заводе номер кузова который надо выбить тоже вот так вот в ручном режиме велся, т. е. там была пресс-форма и рабочий просто в ручном режиме проворачивал кольцо в цифровом блоке, нажимал кнопку, номер выбивался на кузове, а он в журнал записывал пробитый номер. Ну такая себе автоматизация, но по факту, иногда рабочий забывал провернуть колесо или не записал последний номер в конце смены, ну и следующий кузов выходил с номером двойником, что потом вызвало проблемы при регистрации такого «чуда» после покупки такого авто. Ну там шеф вхож в большие круги, заводик все таки автомобильный, поэтому приняли положение, что номер кузова может быть со слешем, который использовали для забоя последней цифры, для исключения дублирования, хотя и это им не всегда помогало... Жаль, что не все кто внедряет у себя систему тоже так не вхожи в разные большие комитеты :-), а то проблем бы не было.
 

3. Автоматическое формирование номера кассового ордера в поле «Ссылочный номер документа» - не очень похоже на автоматизацию, при такой реализации могут быть проблемы при одновременной параллельно работе нескольких кассиров, оба в момент запроса получат одинаковый максимальный номер из таблицы TCJ_DOCUMENTS. Опять же предлагается ручное заполнение разрывов нумерации, ну т. е. вот это самое появление разрывов, например при сторно, нужно хранить где-то на бумажках, чтобы потом использовать при операции.
 

4. В качестве номера кассового ордера используется номер FI-документа сформированного на основании кассового ордера — Ну тут какой-то совсем дас ист фантастишь, потому что, «В случае работы в кассе нескольких кассиров, кассир сохраняет документ, после этого звонит главному кассиру, который этот документ проводит», это зачетно, т. е. главный кассир он всегда на месте, хотя работа наверное такая. Далее предлагается использовать объекты интервалов номеров, аналог пункта 1, при этом я не так и не понял почему не образуется разрывов? Нумерация документов FI идет всегда вперед, если что-то где-то при проводке документа упадет, то номер будет пропущен и затолкать документ с пропущенным номером, уже будет не тривиально. Далее при нескольких серверах приложений получите такую же проблему как и при методе 1 из-за буферизации интервала на сервере приложения.
 

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

Комментарий от  

Сергей Прянишников

  |  06 июля 2013, 10:39

Сложилось впечатление, что существует недопонимание, как работает генератор диапазонов номеров в SAP. В общем виде можно получить непрерывность номеров в системе, для этого надо чуток докрутить метод 3, но про это ниже.
 
1. Нумерация кассовых ордеров ведется в поле “Номер документа кассовой книги для просмотра” - Стандартное решение от SAP, ну кроме того что как было отмечено нельзя получить интервалы без разрыва, но и что более как мне кажется проблематично, это нельзя гарантировать постоянное увеличение номеров при нескольких серверах приложений, так как система произведет чтение номера из интервала, при этом каждый сервер приложение получит по номеру, далее если номер на каком-то из серверов использовался, система запросит следующий номер, но первый сервер приложения будет ждать своей очереди и может возникнуть ситуация когда нумерация будет выдана в таком порядке как 1<первый сервер>, 3<первый сервер>, 4<первый сервер>, 5<первый сервер>, 6<первый сервер>, 2<второй сервер>, 7<первый сервер>, что приводит пользователей в некоторое состояние задумчивости, особенно если номер 2 появится на следующий день.
 
2. Нумерация кассовых ордеров ведется в поле «Ссылочный номер документа» - Ну это уже какое-то ручное бессистемное извращение. На одном очень автомобильном заводе номер кузова который надо выбить тоже вот так вот в ручном режиме велся, т. е. там была пресс-форма и рабочий просто в ручном режиме проворачивал кольцо в цифровом блоке, нажимал кнопку, номер выбивался на кузове, а он в журнал записывал пробитый номер. Ну такая себе автоматизация, но по факту, иногда рабочий забывал провернуть колесо или не записал последний номер в конце смены, ну и следующий кузов выходил с номером двойником, что потом вызвало проблемы при регистрации такого «чуда» после покупки такого авто. Ну там шеф вхож в большие круги, заводик все таки автомобильный, поэтому приняли положение, что номер кузова может быть со слешем, который использовали для забоя последней цифры, для исключения дублирования, хотя и это им не всегда помогало... Жаль, что не все кто внедряет у себя систему тоже так не вхожи в разные большие комитеты :-), а то проблем бы не было.
 

3. Автоматическое формирование номера кассового ордера в поле «Ссылочный номер документа» - не очень похоже на автоматизацию, при такой реализации могут быть проблемы при одновременной параллельно работе нескольких кассиров, оба в момент запроса получат одинаковый максимальный номер из таблицы TCJ_DOCUMENTS. Опять же предлагается ручное заполнение разрывов нумерации, ну т. е. вот это самое появление разрывов, например при сторно, нужно хранить где-то на бумажках, чтобы потом использовать при операции.
 

4. В качестве номера кассового ордера используется номер FI-документа сформированного на основании кассового ордера — Ну тут какой-то совсем дас ист фантастишь, потому что, «В случае работы в кассе нескольких кассиров, кассир сохраняет документ, после этого звонит главному кассиру, который этот документ проводит», это зачетно, т. е. главный кассир он всегда на месте, хотя работа наверное такая. Далее предлагается использовать объекты интервалов номеров, аналог пункта 1, при этом я не так и не понял почему не образуется разрывов? Нумерация документов FI идет всегда вперед, если что-то где-то при проводке документа упадет, то номер будет пропущен и затолкать документ с пропущенным номером, уже будет не тривиально. Далее при нескольких серверах приложений получите такую же проблему как и при методе 1 из-за буферизации интервала на сервере приложения.
 

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

Сергей, спасибо за полезный комментарий.
Таблица со списком сторнированных документов для метода 3 это хорошая идея.
Зря вы так про метод 4. Метод абсолютно рабочий. Вполне успешно применяется на практике. Вероятно при нескольких серверах приложений действительно возникнет описанная вами проблема, но при более простой конфигурации все Ок.
Метод с ручным заполнением номера ордера тоже на мой взгляд вполне достойный вариант. На многих предприятиях также вполне успешно работает.

Комментарий от  

Сергей Прянишников

  |  06 июля 2013, 10:40

Сергей, спасибо за полезный комментарий.
Таблица со списком сторнированных документов для метода 3 это хорошая идея.
Зря вы так про метод 4. Метод абсолютно рабочий. Вполне успешно применяется на практике. Вероятно при нескольких серверах приложений действительно возникнет описанная вами проблема, но при более простой конфигурации все Ок.
Метод с ручным заполнением номера ордера тоже на мой взгляд вполне достойный вариант. На многих предприятиях также вполне успешно работает.

Прошу прощения по ошибке назвал вас Сергеем.

Комментарий от  

Олег Точенюк

  |  06 июля 2013, 11:34

Прошу прощения по ошибке назвал вас Сергеем.

Да не страшно. Просто я чаще работал когда серверов приложение было 2 и больше и там когда первый раз попал на такую штуку с номерами документов (кажется это были счета-фактуры), сначала не мог понять в чем фишка, почему вдруг в интервал влезал номер значительно меньший чем текущие номера, причем там разрыв был типа уже идут номера порядка 10001 и вдруг появляется номер 400. Поэтому с этим методом реализации, нужно быть осторожным.
 
Ну а ручное заполнение, да вариант, но мы то типа автоматизируем процессы :-)

Комментарий от  

Сергей Теплов

  |  08 августа 2013, 09:16

В 4-ом способе будет разрыв нумерации при сторно.
Этот абзац непонятен:
"В случае необходимости проведения сторно кассового ордера это возможно сделать как методов ввода обратного кассового ордера либо функции сторно в кассовой книге. При этом не образуется разрывов в нумерации кассовых ордеров."