Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0021120
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Retail Modules] Web POSmajoralways2012-07-16 20:042012-07-17 10:19
ReporterxplacescView Statuspublic 
Assigned Toalostale 
PriorityhighResolutionno change requiredFixed in Version
StatusclosedFix in branchpiFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0021120: Cash up is not working in White Valley

DescriptionCash up is not working for White Valley. It works for F&B.
Steps To Reproduce1) Connect to web POS as vallblanca
2) Execute Cash Up
3) The cash count step shows the pending amount. In fact it shows big amounts now, as it would not been completed for some time
4) Finish the process
5) Financial account movements in the BO have not been done. If you try to execute again Cash Up in the web pos, it shows same pending amounts

I've tried to compare the set up for Vall Blanca Store (the used here) and F&B Inc (the one used for F&B), and I've been only able to see these 2 differences:
1) Vall Blanca Store is a Generic type organization, while F&B Inc is Legal with Accounting (apart of that we are for White Valley using the spanish loc pack)
2) With Vall Blanca we are managing in EUR, while for F&B in USD

Proposed SolutionIn this case, application should provide an error message. Process in web pos finishes ok, but it has done nothing.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
has duplicate defect 0021112 closedalostale Grouped Invoice is not generated after a Cash Up 

-  Notes
(0050640)
xplacesc (reporter)
2012-07-16 20:06

Sorry, I think this is same that https://issues.openbravo.com/view.php?id=21112 [^]
(0050641)
alostale (manager)
2012-07-17 09:43

This is the error in the log:

df446511 2012-07-17 07:40:19,406 [ajp-8809-2] ERROR org.openbravo.retail.posterminal.ProcessCashClose - Error processing cash close
org.openbravo.base.exception.OBSecurityException: Organization 67839EEFA49E44AC969BD60093FCC899 of object (FIN_Payment_ScheduleDetail(4C8EF2337D8041E9BCC3E15E3AE3662E) (paymentDetails: 01690A9F4DC34804B4C5E7B4BB18E0EB, orderPaymentSchedule: 632F08367A6A4A0C99DD1AB6635C21FB, invoicePaymentSchedule: FB108D0A37344DCAA0E62CB4702E2D67, amount: 14.5)) is not present in OrganizationList [D270A5AC50874F8BA67A88EE977F8E3B]
    at org.openbravo.dal.security.SecurityChecker.checkWriteAccess(SecurityChecker.java:186)
    at org.openbravo.dal.core.OBInterceptor.doEvent(OBInterceptor.java:339)
    at org.openbravo.dal.core.OBInterceptor.onFlushDirty(OBInterceptor.java:180)
    at org.hibernate.event.def.DefaultFlushEntityEventListener.invokeInterceptor(DefaultFlushEntityEventListener.java:372)
    at org.hibernate.event.def.DefaultFlushEntityEventListener.handleInterception(DefaultFlushEntityEventListener.java:349)
    at org.hibernate.event.def.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:287)
    at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:155)
    at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219)
    at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99)
    at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
    at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
    at org.openbravo.dal.service.OBDal.flush(OBDal.java:191)
    at org.openbravo.retail.posterminal.OrderGroupingProcessor.groupOrders(OrderGroupingProcessor.java:153)
    at org.openbravo.retail.posterminal.ProcessCashClose.exec(ProcessCashClose.java:38)
    at org.openbravo.retail.posterminal.TerminalServlet.execClassName(TerminalServlet.java:154)
    at org.openbravo.retail.posterminal.TerminalServlet.doGetOrPost(TerminalServlet.java:76)
    at org.openbravo.retail.posterminal.TerminalServlet.doPost(TerminalServlet.java:47)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
    at org.openbravo.base.HttpBaseServlet.serviceInitialized(HttpBaseServlet.java:225)
    at org.openbravo.base.secureApp.HttpSecureAppServlet.service(HttpSecureAppServlet.java:428)
    at org.openbravo.client.kernel.BaseKernelServlet.callServiceInSuper(BaseKernelServlet.java:87)
    at org.openbravo.retail.posterminal.WebServiceAuthenticatedServlet.service(WebServiceAuthenticatedServlet.java:51)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.openbravo.utils.SessionExpirationFilter.doFilter(SessionExpirationFilter.java:66)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.openbravo.utils.CharsetFilter.doFilter(CharsetFilter.java:35)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.openbravo.client.kernel.KernelFilter$1.doAction(KernelFilter.java:62)
    at org.openbravo.dal.core.ThreadHandler.run(ThreadHandler.java:46)
    at org.openbravo.client.kernel.KernelFilter.doFilter(KernelFilter.java:71)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.openbravo.dal.core.DalRequestFilter$1.doAction(DalRequestFilter.java:81)
    at org.openbravo.dal.core.ThreadHandler.run(ThreadHandler.java:46)
    at org.openbravo.dal.core.DalRequestFilter.doFilter(DalRequestFilter.java:103)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
    at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:429)
    at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:384)
    at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555)
    at java.lang.Thread.run(Thread.java:636)
(0050643)
alostale (manager)
2012-07-17 10:11

The problem is caused because a payment schedule associated with one of the orders created for this terminal is in an incorrect organization. Most probably, this was generated having before fixing some bug.

openbravo=# select g.name, count(*) from ad_org g, c_order o, fin_payment_schedule s where em_obpos_applications_id='9104513C2D0741D4850AE8493998A7C8' and o.c_order_id = s.c_order_id and g.ad_org_id = s.ad_org_id group by g.name;
          name | count
------------------------+-------
 Vall Blanca Store | 66
 The White Valley Group | 1
(2 rows)
(0050644)
alostale (manager)
2012-07-17 10:19

As workaround I temporary gave access to The White Valley Group organization to VallBlancaUser role, did the cash up and removed the access.

From now on this problem shouldn't appear again as organizations should be properly managed.

- Issue History
Date Modified Username Field Change
2012-07-16 20:04 xplacesc New Issue
2012-07-16 20:04 xplacesc Assigned To => adrianromero
2012-07-16 20:06 xplacesc Note Added: 0050640
2012-07-17 09:19 alostale Status new => scheduled
2012-07-17 09:19 alostale Assigned To adrianromero => alostale
2012-07-17 09:19 alostale fix_in_branch => pi
2012-07-17 09:43 alostale Note Added: 0050641
2012-07-17 10:11 alostale Note Added: 0050643
2012-07-17 10:19 alostale Note Added: 0050644
2012-07-17 10:19 alostale Status scheduled => closed
2012-07-17 10:19 alostale Resolution open => no change required
2012-07-17 10:19 alostale Relationship added has duplicate 0021112


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker