Class MovementAdminAction

java.lang.Object
org.apache.struts.action.Action
org.apache.struts.actions.BaseAction
org.apache.struts.actions.DispatchAction
org.bgerp.action.base.BaseAction
org.bgerp.plugin.inventoru.action.QueueScreenAction
org.bgerp.plugin.inventoru.action.MovementAdminAction
public class MovementAdminAction extends QueueScreenAction
Receipt and inventory-count adjustment of stock, over the journal of movements. Each operation goes by its permission node: by default to the stores the user runs (their editing groups), a warehouse admin to every store, the option stores of the node widens or narrows it — see checkTarget(Connection, DynActionForm, String, int, int). The journal itself is a queue like every other entity's (QueueScreenAction): it used to be a warehouse picker and the last 500 rows of that one warehouse, cut off without a word and with nothing to filter or page by — a journal that cannot be asked a question is a wall of text. Reading it and writing into it go by different rules, deliberately. Whose movements a person may read is one question with one answer for the whole plugin — QueueEntity.accessRestriction(Connection, DynActionForm) over the warehouses they work with — and it holds here exactly as on the user screen, so the same journal never answers differently depending on which door it was opened by. Writing is narrower: a receipt or a correction reaches only the warehouses of the person's editing groups (see checkTarget(Connection, DynActionForm, String, int, int)), because putting stock somewhere is a stronger claim than knowing what stands there. The old screen tied reading to the write rule as a side effect of listing the warehouses of the picker, not by intent; the rows it hid are ones the same person could read on the user screen anyway. The journal is still behind its own nodes (queueFilter, queueShow), so an existing install shows nothing here until they are granted. Mapped at /admin/plugin/inventoru/movement.do

  • Constructor Details

    • MovementAdminAction

      public MovementAdminAction()

  • Method Details

    • unspecified

      public org.apache.struts.action.ActionForward unspecified(DynActionForm form, ConnectionSet conSet) throws Exception
      Description copied from class: BaseAction
      Default action method if no parameter 'action' passed. Overwrite and implement.
      Overrides:
      unspecified in class BaseAction
      Parameters:
      form -
      conSet -
      Returns:
      the action forward
      Throws:
      Exception

    • queueFilter

      public org.apache.struts.action.ActionForward queueFilter(DynActionForm form, ConnectionSet conSet) throws Exception
      Throws:
      Exception

    • queueShow

      public org.apache.struts.action.ActionForward queueShow(DynActionForm form, ConnectionSet conSet) throws Exception
      Throws:
      Exception

    • getEntity

      protected QueueEntity getEntity()
      Description copied from class: QueueScreenAction
      The entity the screen lists.
      Specified by:
      getEntity in class QueueScreenAction

    • getScreenTitle

      protected String getScreenTitle(DynActionForm form)
      Description copied from class: QueueScreenAction
      Screen title, shown in the browser tab.
      Specified by:
      getScreenTitle in class QueueScreenAction

    • getShowAction

      protected String getShowAction()
      Description copied from class: QueueScreenAction
      Permission node of the card the rows link to, e.g. /user/plugin/inventoru/store:show; the row menu is hidden without it.
      Specified by:
      getShowAction in class QueueScreenAction

    • getToolbarJsp

      protected String getToolbarJsp()
      Description copied from class: QueueScreenAction
      Entity specific buttons shown above the queue selector — creating a row, opening a related catalogue. The queue itself has no idea what can be done with what it lists.
      Overrides:
      getToolbarJsp in class QueueScreenAction
      Returns:
      path of a JSP to include, or null when the entity has no such buttons.

    • receipt

      public org.apache.struts.action.ActionForward receipt(DynActionForm form, ConnectionSet conSet) throws Exception
      Manual stock-in, independent of the 1C import — closes the gap where the only way to add quantity to the ERP was via 1C sync (nothing to do if 1C is down, or the material never had a 1C nomenclature entry to begin with).
      Throws:
      Exception

    • adjust

      public org.apache.struts.action.ActionForward adjust(DynActionForm form, ConnectionSet conSet) throws Exception
      Corrects the recorded quantity to match an actual physical count (инвентаризация). The admin enters the counted (actual) quantity, not a delta — recording the delta as an 'adjustment' movement is an implementation detail the operator shouldn't have to compute by hand. A reason is mandatory: this silently changes what the system believes is true, so an unexplained correction is not acceptable audit trail.
      Throws:
      Exception

    • writeoffUnit

      public org.apache.struts.action.ActionForward writeoffUnit(DynActionForm form, ConnectionSet conSet) throws Exception
      Writes off one unit by its serial number: the only way a wrongly placed unit leaves a warehouse without a process behind it. Until this existed the two sides of such a mistake locked each other. The card of the unit refused deletion while the unit stood on a warehouse ("спишите его, потом удаляйте"), the warehouse field of the card could not be emptied, moving the unit elsewhere changed nothing, and a stocktaking correction refused to take the balance below the units standing there — telling the person to write those units off by serial, which no screen offered. Equipment imported by mistake stayed on the books of an installer for good. The movement does both halves of the cleanup at once: the balance of the position drops by one and the unit goes off every warehouse (see MovementDAO.moveDevices), after which the card deletes as any other. Everything else — a unit under an active reserve, a warehouse whose units 1C keeps — is refused by the DAO, the same rules as for any write-off.
      Throws:
      Exception