Hello Everyone, First of all, thanks so much for all the responses and an interesting discussion. Apologies for the late response because of the time difference.
As I gather from all the posts, I can select / edit the order dates programmatically. Whether this should be done principally is the question. I am working with a food processing company having multiple warehouses spread across US which are rented for short/long duration. Many times, the order pickup information is conveyed late to the company (Offline process) which leads to such scenarios. If someone is late by couple of days doesn't make any difference from accounting point of view. But when it comes to a date such as December 30th, it creates a huge difference because of the Financial Year change (US new financial year starts Jan 1) and invites troubles of journal entries to effect the transaction in the past year. I am sure every organisation comes across such a scenario. It will be interesting to understand how this situation is tackled. My question is, if we change the Sales Order Date and Sales Order Packing Date, what date will be considered for the following Accounting Transactions? (I have not considered changing the Invoice date, and effective payment date which add more variables to the situation.) 1. Txn date for Accounts Receivable entry 2. Txn date for reducing the Assets Thanks once again. Sarang Systematrix Solutions On Wed, May 21, 2014 at 9:05 AM, Paul Mandeltort <[email protected]> wrote: > Always a difficult question - where do you draw the line between systemic > controls vs. training? > > At the minimum if we don’t have a security provision, we should have > proper auditing of when a PO receipt is backdated or postdated, so someone > can figure out > > While I wasn’t around for the initial decisions to make the dates not > editable, in a large organization this could potentially have drastic > results for other users in the organization. > > The scenario I can imagine (and has happened in my org before) is a > purchase order contract dispute. Since purchase orders are legal contracts > (at least in the USA), there is a potential if a PO is received late, and > there is not a proper record of when the PO was received by the company, > that you run into a problem. > > My organization, for example, doesn’t use OFbiz’s inbound package tracking > functionality (too complicated and slow). > > Yeah, better training and supervision would fix this problem, but the > reality is that most organizations would overlook a little thing like this, > especially if the default old behavior changes between upgrades. > > Having it available just at a supervisor level at least mitigates that > problem. Or at least stubbing it so it’s easy to figure out where to add > the security control would be a good start. > > --Paul > ---------- > Paul Mandeltort | Marco Specialties Inc > +1-512-394-8119 | [email protected] > > On May 21, 2014, at 7:15 AM, Pierre Smits <[email protected]> wrote: > > > Paul, > > > > Are you sure you would add complexity to a system to provision for > > avoidance of laziness? Better is it to improve business processes and > > procedures to flesh such behaviour out of the organisation. > > > > Regards, > > > > Pierre Smits > > > > *ORRTIZ.COM <http://www.orrtiz.com>* > > Services & Solutions for Cloud- > > Based Manufacturing, Professional > > Services and Retail & Trade > > http://www.orrtiz.com > > -- Regards, Sarang
