A change log across eleven modules recording the field changed, the value before, the value after, the user and the timestamp, read from a tab inside the record. Filter by date and value, extend it to style quantity movements, and pair it with role based access control.
Most arguments inside a brand are about a value that used to be something else. The ship date that moved. The quantity that shrank. The terms nobody remembers agreeing to. AIMS360 keeps a change log on the records where that happens, showing the field, the old value, the new value, the user and the timestamp, on a tab inside the record itself.
Yes. AIMS360 tracks changes made by users across the modules a wholesale business actually argues about, and records what each item was changed from, when, and by whom. It is not a separate reporting module you go and run. It is a tab inside the record, so the history of an order sits on the order.
In AIMS360 that tab is called the Time Machine. The name is friendlier than the function, which is a plain change log: every tracked field that moved, with its previous and new value against a named user and a timestamp.
| Column | What it holds |
|---|---|
| User | The AIMS360 user who was logged in when the change was made. This is the argument for individual logins rather than a shared one: a shared login makes every line of the log say the same useless thing. |
| Date and time | When the change happened, which is usually the detail that settles the question of whether it was before or after the order was confirmed. |
| Field | Which value on the record changed. The fields available depend on the module you are looking at. |
| Previous value | What it said beforehand. On a freshly created record there is nothing here, because there was no earlier version. |
| New value | What it says now. On creation this column carries the original values the record was set up with, so the first line doubles as a snapshot of how it started. |
A worked example. Somebody opens a customer order, changes the quantities by size and switches the terms to net 30. Reopen the change log afterwards and both edits are there as separate lines: quantity by size with its old and new numbers, terms with its old and new value, both against the same user and timestamp. Nothing had to be turned on for that to be recorded.
Eleven modules, chosen because they are where the money and the disputes are.
| Module | What the log is good for there |
|---|---|
| Customer orders | Quantities by size, terms, dates, ship to, discounts, status. The most contested record in a wholesale business and the one people ask about most. |
| Invoices | What was billed, at what price, on what terms, and every edit made to it after the fact. |
| Customers | Credit terms, addresses, contacts, factor details, price category. The setup changes that quietly alter how every future order behaves. |
| Pick tickets | What was released to the warehouse and every change made to it before it shipped. |
| Styles | The style record: description, season, prices, dates, costing, attributes. Optionally quantity movements too, see below. |
| Vendor purchase orders | What you ordered from a factory or mill, at what price, for what dates, and what changed after it was raised. |
| Cut tickets | Production quantities, dates and detail on domestic cut and sew work. |
| Garment dye | Dye lot production records and the changes made against them. |
| RMA and credit memos | Returns and credits, which is where disputes about what was actually agreed tend to end up. |
| Shipment processing | What was packed and shipped against the order, and any correction made afterwards. |
| ASN shipments | The advance ship notice sent to a retailer, which is the version of events the retailer holds you to. |
The vendor master is on the list to be added rather than covered today. If vendor record changes are something you need evidence of now, say so during your evaluation rather than assuming, and we will tell you where that stands. The list of tracked modules has grown over time and it is worth checking rather than working from an old answer.
Go to the customer order, invoice, style or purchase order in question and open its change log tab. You are already looking at the right record, so there is nothing to search for.
Set a date period with a start and end date. On anything with real history this is the difference between reading a list and scanning a wall.
Filter on a value with an operator to isolate a specific change rather than everything that happened that week, then apply it. Reset clears everything back.
Current versions show a window of dates at a time, with next and previous controls, so a heavily edited order loads quickly instead of trying to render everything at once.
If your brand runs unusually heavy transaction volumes and the log is still slow to load after filtering, further pagination can be enabled on your database. It is a request to us rather than a setting you toggle, so mention it if you hit it.
By default the style change log covers the style record. An additional setting extends it to quantity changes reaching that style from elsewhere. Turn it on and the style log also shows movements from work in process, stock adjustments and orders, with the user behind each one.
This is the setting to ask about if your recurring question is not what somebody typed on the style but why the on hand number is different from what you expected. Without it you can see that costing was updated last Thursday. With it you can also see that a pick ticket took forty units and a stock adjustment added twelve, and who did each.
Quantity coming in or moving through production against that style, attributed to the user who processed it.
Manual adjustments to on hand, which is the category that most often needs explaining at month end.
Quantity effects arriving from the order side rather than from someone editing the style itself.
The ordinary style record changes such as costing and pricing continue to be logged alongside the quantity lines.
Allocation has its own audit report rather than a per record tab, because a single run touches hundreds of order lines. Set a date range, filter by order or style, and review every allocation and change at style, color and size level. It exports to Excel, which is how most merchandisers want to read it. See intelligent allocation.
An administrator can review every email AIMS360 sent: the user who created it, the from address, the recipient, CC and BCC, subject and date. Automated invoice emails also carry a delivery status, so delivered, opened, clicked, bounced and failed are all visible. Manually sent emails carry no status, because nothing is tracking them once they leave.
A log tells you what happened. Role based access control decides what can happen. Splitting who creates an order, who approves a credit and who releases a payment across different roles is the internal control an accountant or a factor expects to see, and it makes the log far more meaningful because the names on it mean something.
Mandatory notes on stock adjustments booked as Other, and the notes and tasks on customers and orders, are where the context lives. The log records the movement. The note records the reason, and six months later the reason is the part nobody can reconstruct.
When a retailer says the ship window or the price was different, the log shows the original value, the change, the person and the date. That turns a disagreement into a lookup, and it is equally useful when sales and the warehouse disagree internally. See chargeback management.
Auditors care that a number in a report can be walked back to the transaction and the person behind it. A change log plus separated duties gives you that path without anybody reconstructing it from memory at year end.
The most valuable use is unglamorous. When the same mistake keeps appearing, the log shows whether it is one person who needs ten minutes of training or a process that invites the error. That is worth more than catching anybody out.
It also changes behavior quietly. In a system where changes are attributed, people check before they edit, which is a smaller benefit to describe and a larger one to live with.
The log shows the previous value so a person can decide what to do about it. It does not restore anything by itself. Restoring the database to an earlier moment is backup and point in time recovery, and the two get confused often enough to be worth stating plainly.
Eleven modules are tracked, and vendors is not yet one of them. If the record you most need history on is outside that list, the honest answer is to check with us rather than assume the whole system is logged.
How far back the history goes depends on your plan, the module and the status of the record. There is no single number that is true for every customer, so if you are counting on the log to still be there next year, ask what applies to your database rather than working from a general answer.
Every entry names the user who was signed in. One shared login across a department produces a log where every line names the same account, which tells you nothing. Individual logins with roles are what make the log evidence rather than trivia.
Yes. AIMS360 keeps a change log across the modules that matter operationally, including customer orders, invoices, customers, pick tickets, styles, vendor purchase orders, cut tickets, garment dye, RMAs and credit memos, shipment processing and ASN shipments. Each entry records the field that changed, the value before, the value after, the user who made the change and the date and time. It appears as a tab inside the record itself, so you read the history without leaving the order or the invoice you are looking at.
A chronological record of who changed what, when, and what the value was beforehand. The point is not paperwork, it is being able to answer a question after the fact: why does this order say net 60 when it was quoted net 30, who reduced this quantity, when did this price change. Without one those questions get answered from memory, which is how disagreements between departments and with customers turn into standoffs.
Four things: the field, the previous value, the new value, and the user and timestamp. On a newly created record there is no previous value, so the log shows the original values it was created with, which is a useful baseline. From then on every edit adds a line.
Customer orders, invoices, customers, pick tickets, styles, vendor purchase orders, cut tickets, garment dye, RMAs and credit memos, shipment processing and ASN shipments. Vendors is on the roadmap rather than live today. If a module you rely on is not in that list, tell us, because the list has grown over time.
Inside the record, as its own tab in the module navigation. Open the customer order, the invoice or the style and the history is right there. On records with a lot of tabs you may need to scroll the navigation to find it.
Yes. You can filter by date period with a start and end date, and by value and operator, then apply the filter or reset it. On records with a lot of history, current versions show a chunk of dates at a time with next and previous controls, so a busy order does not try to render years of changes in one go.
Yes. Quantity changes by size on a customer order are exactly the kind of edit the log is designed for, and it shows the previous quantity, the new quantity, who made the change and when. This is the single most common reason brands open the change log.
Yes, with an optional setting. By default the style change log tracks the style record itself, such as description, prices, dates and costing. Turning the additional setting on also records quantity changes reaching the style from work in process, stock adjustments and orders, so you can see which user moved a number and from which module. It is off unless you ask for it.
Retention depends on your plan and on the specific module and the status of the record, so it is not one number across the board. Ask us what applies to your database before you rely on the log for something like a year end review, and we will tell you exactly what your retention looks like.
Yes, separately. Intelligent allocation has its own audit report under Reports, where you set a date range and filter by order or style, then review every allocation and change at style, color and size level for each order line. It exports to Excel, which is usually how a merchandiser wants to review a big allocation run.
Yes. An administrator can open the email log and see the user who created each email, the from address, the recipient, any CC and BCC, the subject and the date. Emails sent through the automation, such as invoices, also carry a delivery status: delivered, opened, clicked, bounced, failed or processed. Emails sent manually do not carry status, because there is nothing tracking them.
Yes, and it is worth turning on. There is a setting that makes the note mandatory when someone books a stock adjustment with a reason code of Other, so the adjustment cannot be saved without a short explanation. It closes the gap where the log tells you a number moved but not why.
No, and it is important not to confuse the two. The change log tells you what a value was before it was changed, so you can put it back yourself if that is the right answer. Actually rolling a database back to an earlier moment is a different capability, covered by continuous backup and point in time recovery.
It helps in the way auditors actually care about, which is traceability: a figure in a report can be walked back to the transaction that produced it and to the person who entered or changed it. Combined with role based access control, so that creating, approving and paying sit with different people, it gives you the separation of duties and the evidence trail that accountants, factors and auditors look for. AIMS360 does not make claims about specific certification schemes.
Access follows your permissions. Because roles control what each user can open, you decide whether a change log is visible to everyone working in a module or only to supervisors and administrators. The email log is administrator only.
Not in normal use. On records with a very large number of entries the log can take a moment to load, which is why the date filter exists and why current versions page through history rather than loading all of it. For brands with unusually heavy volumes there is an option to paginate the entries further, which we can enable on request.
It is not a document users maintain. The log is written as changes happen, which is the whole reason it is worth anything as evidence. If you need it locked down further, the right lever is permissions: restrict who can reach the records in the first place.
Because most disputes are about what was agreed and when it changed. When a retailer says the ship window moved or the price was different, the change log shows the original value, the new value, who changed it and on what date. That turns an argument into a lookup, which is the same reason it is useful internally when sales and warehouse disagree about an order.
The connectors answer over live AIMS360 data, so questions about your records can be asked in plain language rather than run as a report. What any given assistant can reach depends on the permissions behind the connection, so scope it with us rather than assuming.
The order that shipped short. The price that was right last week. The stock figure two people swear they did not touch. Show us one of those and we will walk through exactly where the answer would have been, and what it takes to have it next time.
