Venture’s pricing service uses a uniform file format to update existing item costs / prices, add new items and inactivate obsolete items.
The file format:
VENDOR CODE, Part Numbe, UPC Cod, Unit of Measur , Descriptio, Discount Group, Manufacturer List Price, Dealer/Distributor Net Price, QTY each per unit of measure, Weight, Depth, Width, Height
Scenario: Joe Parts-Counter gets a fresh load of widgets off the loading dock and decides to help receiving out by doing their paperwork. Oh, Joe… we appreciate the effort but make sure you receive the correct PO!
Too late.
There’s a quick fix to right Joe’s wrong. In this scenario we assume that the PO was received but none of the stock was allocated. If stock was allocated we have a slightly more complicated situation to deal with and we’ll cover that in a later article.
First, make manual stock adjustments to reset the stock receipt for each item put into stock.
Next, reference venture-scripts/fixup/PODueInFixup.php
Run the program with the proper po header ID reference:
./PODueInFixup.php po_header_id
That script will reset the received quantities on the PO to zero and readjust the due-in counts in the item_warehouse_master.
The PO is now ready to be received when the actual order arrives!
OK Joe, back to the sales counter.
Permissions aren’t very hard to deal with, so I thought I’d just write a short how-to.
To get to permissions, in the main menu go to: Administration->Permissions->Permission Master
There are two main tabs on the top of the permissions page, the first page which you default to assigns permissions to users and roles. There’s two sub-tabs on this first page that alternates between assigning permissions to either roles or employees.
Employees can be a member of one role, and from a maintenance standpoint it’s easier to maintain perms if you create roles, assign permissions to them, then assign employees to the role. You can create a new role by right clicking in the box that shows roles on the first page.
When assigning permissions to employees or roles, you only see the permissions on the left that the employee/role doesn’t already have.
You just use the arrow buttons to assign/revoke permissions.
On the second page which shows employees on the left and roles on the right only shows employees that aren’t assigned to any roles. Since I put all employees I didn’t know what to do with in a default role, in order to assign them to a new role you’ll first need to remove them from that default role, then assign them to the new role.
Changes happen in real-time, as soon as you give/revoke permissions to a group or role, they immediately have those permissions.
One permission not to forget about is the “Login” permission, it’s in the “Company” group. If you have super user you don’t need that, but in order to login to Venture you need that permission.
Situation: your Amazon AMTU order file contains items that are not properly referenced in the item master. That amazon request will fail to generate a Venture sales order and complain loudly to the Venture admin via email.
Usually the problem is easily identified — maybe an assembly or new item that your merchandising manager neglected to create in Venture. Amazon errors are usually pretty good and point you right to the problem.
Once the problem is fixed, you can regenerate an Amazon order file and run it again to save the energy and errors associated with hand keying orders. Here’s how:
How to Create an Amazon Order Rerun File
venture-scripts/amazon/mk_order_rerun_file
For parameters, it takes the amazon order file name and one or more amazon
order IDs. For example, for the latest rerun batch I used this command line:
venture-scripts/amazon/mk_order_rerun_file ORDER380643853.txt 104-9147014-4205555
I could have added more order IDs if there had been additional errors. When
the program finished it will display instructions on how to proceed. From
the example run:
Rerun file ‘rerun/RERUN380643853.txt’ has been created. To edit this
file run:
cd /usr/local/amtu/DocumentTransport/production/reports
vi rerun/RERUN380643853.txt
When errors have been corrected perform the following steps as user
‘venture’ to process the order(s):
cd /usr/local/amtu/DocumentTransport/production/reports
mv rerun/RERUN380643853.txt .
From this point, the normal Amazon AMTU process will pick up and process the order file.
Today I encountered a situation where a user had improperly received PO’s and while attempting to fix things managed to incorrectly transfer material. To compound things, the user then made some hard count stock adjustments — again, incorrectly.
I suggested that the user’s permissions be altered. 
Then I suggested a physical count of the items and warehouses involved. The on-hand changes were significant and the count sheet commit process refused to update the wild deltas due to system settings.
When submitting count sheets for approval, Venture will not allow changes greater than a count sheet maximum delta in dollars OR a maximum delta in physical on-hand count. This limit prevents wild swings in inventory without care.
If you need to change the maximum deltas, they are found on the company master. This is maintained from the client by using the menu bar: Administration -> System Maintenance -> Company Master.
The fields are labeled Count Sheet Max $ and Count Sheet Max %.
$: maximum dollars of inventory valuation delta
%: maximum physical count delta
After all of this we changed the maximums back to their original conservative settings.
Please contact us at info@venture.kdsi.net if you have any questions about Venture.
We’d be happy to talk with you about software installation, functions, maintenance and commercial services.
|
